1. Algorithm 每周一道算法题

本周算法题为反转字符串中单词

本题的难点在于如何使用双指针的同时消除边界处理，还是算比较有意思的一道题

2. Review 阅读一篇英文文章

本周在学习结构方面知识时，学习到了单机性能提升的方案，由此接触到了以前对于程序员而言的难题：C10K 问题，因此顺带阅读该文章 The C10K problem

It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now.

难道你不觉得对于 web 服务来说是时候处理 1w 以上的客户端并发访问了吗？毕竟 web 世界已经非常庞大了。

And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to$0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck.

并且计算机也在同步增大。你能用 $1200 轻易买到 2GB RAM、网口速率 1000Mbit/秒，1000MHZ 的机器。让我们来计算一下，20000 个客户端，每个客户端分得频率 50Khz，内存大小100K bytes，网口带宽 50K bits/秒。不应该需要比这更高的处理能力，每秒从磁盘中取出四千字节的数据并发送给二万个客户端的网络。顺便提一下，每个客户端的成本是0.08美元。某些操作系统收取的每个客户端100美元的许可费开始显得有点过高！因此，硬件不再是瓶颈。

In 1999 one of the busiest ftp sites, cdrom.com, actually handled 10000 clients simultaneously through a Gigabit Ethernet pipe. As of 2001, that same speed is now being offered by several ISPs, who expect it to become increasingly popular with large business customers.

在 1999 年最繁忙的 ftp 网址之一——cdrom.com，通过一个 1GB 以太网带宽每秒同时处理 10000 个客户端。到 2001 年，现在有几家互联网服务提供商提供了相同的速度，它们希望这种速度在大型企业中变得越来越受欢迎。

And the thin client model of computing appears to be coming back in style -- this time with the server out on the Internet, serving thousands of clients.

而且瘦客户端模型似乎再次流行起来——这次服务器位于互联网上，服务成千上万个客户端。

With that in mind, here are a few notes on how to configure operating systems and write code to support thousands of clients. The discussion centers around Unix-like operating systems, as that's my personal area of interest, but Windows is also covered a bit.

基于此，以下是一些关于如何配置操作系统和编写代码来支持成千上万个客户端的注意事项。讨论的重点是类 Unix 操作系统，因为那是我个人的研究领域，但也会涉及到一些 windows 系统。

Related Sites

See Nick Black's execellent Fast UNIX Servers page for a circa-2009 look at the situation.

请参阅 Nick Black's 出色的文章 Fast UNIX Servers。

In October 2003, Felix von Leitner put together an excellent web page and presentation about network scalability, complete with benchmarks comparing various networking system calls and operating systems. One of his observations is that the 2.6 Linux kernel really does beat the 2.4 kernel, but there are many, many good graphs that will give the OS developers food for thought for some time. (See also the Slashdot comments; it'll be interesting to see whether anyone does followup benchmarks improving on Felix's results.)

在2003年10月，Felix von Leitner整理了一个出色的网页和演讲，讨论了网络可扩展性，并通过比较各种网络系统调用和操作系统的基准测试。他的观察之一是，2.6版本的Linux内核确实胜过2.4版本的内核，但有很多很好的图表会让操作系统开发人员思考一段时间。（另请参阅Slashdot的评论；有趣的是看看是否有人进行了后续的基准测试，改进了Felix的结果。）

Book to Read First

If you haven't read it already, go out and get a copy of Unix Network Programming : Networking Apis: Sockets and Xti (Volume 1) by the late W. Richard Stevens. It describes many of the I/O strategies and pitfalls related to writing high-performance servers. It even talks about the 'thundering herd' problem. And while you're at it, go read Jeff Darcy's notes on high-performance server design.

如果你还没有读过的话建议去买一本晚期 W. Richard Stevens 写的 Unix Network Programming : Networking Apis: Sockets and Xti (Volume 1) 。它描述了很多关于编写高性能服务的 I/O 策略和陷阱。他甚至还谈到了 'thundering herd' 问题。

(Another book which might be more helpful for those who are using rather than writing a web server is Building Scalable Web Sites by Cal Henderson.)

对于那些更多是使用而不是编写 web 服务的人来说，Cal Henderson 的 Building Scalable Web Sites 似乎更有帮助。

I/O frameworks

Prepackaged libraries are available that abstract some of the techniques presented below, insulating your code from the operating system and making it more portable.

有一些预打包的库可用，它们将下面介绍的一些技术进行了抽象，使得你的代码与操作系统进行隔离，从而增加了代码的可移植性。

后续部分留待下几次阅读。

3. Techniques/Tips 分享一个小技巧

最近在学习极客时间从 0 开始学架构，这门课程对我最大的作用是让我对于学习方向有了比较清晰的认识，知道了作为后端开发人员，成为架构师必要的一些硬性条件，指导了我后续学习的方向，如果你对学习方向有疑虑以及迷茫，建议看一看这门课程，哪怕仅仅看下目录也会有很大收获 ，此外，大厂晋升指南也是一门不可多得的好课，非常具有指导性，建议一读，如果您有比较好的课程，欢迎分享给我 o(^▽^)o

4. Share 分享一个观点

我们很多时候都向往成为一个架构师，但是很多同学只想不做，或者有了梦想，但是不知道方向如何，我以前就是这样，有梦想，但是无头绪，结果就是没有规划的胡乱学习，东一榔头西一榔头，整体知识非常零散，不成体系。

我最开始是做底层框架开发，开发公司自用的 rpc 框架，在这过程中学习到了很多底层知识，但是也让我的学习方向有点跑偏，因为属于基础技术本门，因此接触到的其他基础技术很多，比如注册中心、网关、服务治理、service mesh、function 等，由于在这种环境中导致我觉得要学的东西简直太多了，Java 基础、jvm 原理、CAP、docker、k8s、go、rust 等等，每一个我都力争不能只学皮毛，要学习原理，这导致我 学习速度很慢，并且知识非常零散，学习过程也非常打击信心，因为有些技术底层原理比较复杂，作为初学者其实并不用深入学习，了解大致原理即可。由于一上来就学习很多“新”知识，但是我自身对于“老旧”知识并不了解，这导致我很多时候并不知道一个知识的设计原理，觉得很多内容很难理解，其实只要花点心思学习一下前序知识，很多问题就会迎刃而解，但是很可惜没人告诉我这点，导致我走了很多弯路，走起来也很坎坷。并且由于一直做底层框架开发，从未接触过业务知识，因此很多时候框架功能的开发是想当然的，我们觉得用户应该有需求，就去开发，其实后面我开始接触到业务开发后，才发现以前很多拍脑袋的需求是伪需求，纯属做来感动自己，没有任何业务价值。

在经过三年底层开发以及一年业务开发后，才渐渐知晓了作为新人，应该学习哪些知识：

1. JVM 原理以及 Java 原理
2. 并发编程
3. 网络开发（BIO/NIO，重点学习 Netty）
4. 开发框架（Spring、ORM）
5. 性能优化（可观测、MySQL 优化）
6. 中间件（MySQL、Redis、Zookeeper、Kafka、Elasticsearch）
7. 微服务（RPC、Dubbo、Spring Cloud、服务治理……）
8. 分库分表（Sharding-JDBC）
9. 缓存（Redis）

个人建议按照这些知识进行学习，学习完这些知识后，你就有了架构师的底子，就技术而言基本可以胜任阿里 P7 的等级，后续学习方向无非是领域内知识宽度以及领域外知识广度，当知识宽度足够以后你已经达到阿里 P8 的水平，技术广度足够后就能达到阿里 P9 水平了，这样一说明你是不是就对学习的方向比较清晰了。并且这些技术基本可以囊括大部分技术设计原理，学透了这些技术，后续再学习其他技术就会事半功倍。

目前我还处于第一阶段，还有一些基础性的知识还未学习，希望新的一年内能完成基础知识学习，并且扩充当前业务所属领域内的知识宽度，争取达到阿里 P8 技术水平。