本文原题“聊聊TCP连接耗时的那些事儿”，本次收录已征得作者同意，转载请联系作者。有少许改动。
1、系列文章引言
1.1 文章目的
作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的nget等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不过是皮毛。
返璞归真、回归本质，这些技术特征背后的底层原理到底是什么？如何能通俗易懂、毫不费力真正透彻理解这些技术背后的原理，正是《从根上理解高性能、高并发》系列文章所要分享的。
1.2 文章源起
我（Jack Jiang）为即时通讯网整理了相当多有关IM、消息推送等即时通讯技术相关的资源和文章，从最开始的开源IM框架MobileIMSDK，到网络编程经典巨著《TCP/IP详解》的在线版本，再到IM开发纲领性文章《新手入门一篇就够：从零开发移动端IM》，以及网络编程由浅到深的《网络编程懒人入门》、《脑残式网络编程入门》、《高性能网络编程》、《不为人知的网络编程》系列文章。
越往知识的深处走，越觉得对即时通讯技术了解的太少。于是后来，为了让开发者门更好地从基础电信技术的角度理解网络（尤其移动网络）特性，我跨专业收集整理了《IM开发者的零基础通信技术入门》系列高阶文章。这系列文章已然是普通即时通讯开发者的网络通信技术知识边界，加上之前这些网络编程资料，解决网络通信方面的知识盲点基本够用了。
对于即时通讯IM这种系统的开发来说，网络通信知识确实非常重要，但回归到技术本质，实现网络通信本身的这些技术特征：包括上面提到的线程池、零拷贝、多路复用、事件驱动等等，它们的本质是什么？底层原理又是怎样？这就是整理本系列文章的目的，希望对你有用。
1.3 文章目录
《从根上理解高性能、高并发(一)：深入计算机底层，理解线程与线程池》（* 本文）
《从根上理解高性能、高并发(二)：深入操作系统，理解I/O与零拷贝技术 （稍后发布..）》
《从根上理解高性能、高并发(三)：深入操作系统，彻底理解I/O多路复用 （稍后发布..）》
《从根上理解高性能、高并发(四)：深入操作系统，彻底理解同步与异步 （稍后发布..）》
《从根上理解高性能、高并发(五)：高并发高性能服务器到底是如何实现的 （稍后发布..）》
1.4 本篇概述
本篇是该系列文章的开篇，主要是从CPU这一层来讲解多线程以及线程池原理，力求避免复杂的技术概念罗列，尽量做到通俗易懂、老少皆宜。
2、本文作者
应作者要求，不提供真名，也不提供个人照片。
本文作者主要技术方向为互联网后端、高并发高性能服务器、检索引擎技术，网名是“码农的荒岛求生”，公众号“码农的荒岛求生”。感谢作者的无私分享。
3、一切要从CPU说起
你可能会有疑问，讲多线程为什么要从CPU说起呢？原因很简单，在这里没有那些时髦的概念，你可以更加清晰的看清问题的本质。
实际情况是：CPU并不知道线程、进程之类的概念。
CPU只知道两件事：
- 1）从内存中取出指令；
- 2）执行指令，然后回到 1）。
你看，在这里CPU确实是不知道什么进程、线程之类的概念。
接下来的问题就是CPU从哪里取出指令呢？答案是来自一个被称为Program Counter（简称PC）的寄存器，也就是我们熟知的程序计数器，在这里大家不要把寄存器想的太神秘，你可以简单的把寄存器理解为内存，只不过存取速度更快而已。
PC寄存器中存放的是什么呢？这里存放的是指令在内存中的地址，什么指令呢？是CPU将要执行的下一条指令。
那么是谁来设置PC寄存器中的指令地址呢？
原来PC寄存器中的地址默认是自动加1的，这当然是有道理的，因为大部分情况下CPU都是一条接一条顺序执行，当遇到if、else时，这种顺序执行就被打破了，CPU在执行这类指令时会根据计算结果来动态改变PC寄存器中的值，这样CPU就可以正确的跳转到需要执行的指令了。
聪明的你一定会问，那么PC中的初始值是怎么被设置的呢？
在回答这个问题之前我们需要知道CPU执行的指令来自哪里？是来自内存，废话，内存中的指令是从磁盘中保存的可执行程序加载过来的，磁盘中可执行程序是编译器生成的，编译器又是从哪里生成的机器指令呢？答案就是我们定义的函数。
注意是函数，函数被编译后才会形成CPU执行的指令，那么很自然的，我们该如何让CPU执行一个函数呢？显然我们只需要找到函数被编译后形成的第一条指令就可以了，第一条指令就是函数入口。
现在你应该知道了吧，我们想要CPU执行一个函数，那么只需要把该函数对应的第一条机器指令的地址写入PC寄存器就可以了，这样我们写的函数就开始被CPU执行起来啦。
你可能会有疑问，这和线程有什么关系呢？
4、从CPU到操作系统
上一小节中我们明白了CPU的工作原理，我们想让CPU执行某个函数，那么只需要把函数对应的第一条机器执行装入PC寄存器就可以了，这样即使没有操作系统我们也可以让CPU执行程序，虽然可行但这是一个非常繁琐的过程。
我们需要：
- 1）在内存中找到一块大小合适的区域装入程序；
- 2）找到函数入口，设置好PC寄存器让CPU开始执行程序。
这两个步骤绝不是那么容易的事情，如果每次在执行程序时程序员自己手动实现上述两个过程会疯掉的，因此聪明的程序员就会想干脆直接写个程序来自动完成上面两个步骤吧。
机器指令需要加载到内存中执行，因此需要记录下内存的起始地址和长度；同时要找到函数的入口地址并写到PC寄存器中，想一想这是不是需要一个数据结构来记录下这些信息。
数据结构大致如下：
struct *** {
void* start_addr;
intlen;
void* start_point;
...
};
接下来就是起名字时刻。
这个数据结构总要有个名字吧，这个结构体用来记录什么信息呢？记录的是程序在被加载到内存中的运行状态，程序从磁盘加载到内存跑起来叫什么好呢？干脆就叫进程（Process）好了，我们的指导原则就是一定要听上去比较神秘，总之大家都不容易弄懂就对了，我将其称为“弄不懂原则”。
就这样进程诞生了。
CPU执行的第一个函数也起个名字，第一个要被执行的函数听起来比较重要，干脆就叫main函数吧。
完成上述两个步骤的程序也要起个名字，根据“弄不懂原则”这个“简单”的程序就叫操作系统（Operating System）好啦。
就这样操作系统诞生了，程序员要想运行程序再也不用自己手动加载一遍了。
现在进程和操作系统都有了，一切看上去都很完美。
5、从单核到多核，如何充分利用多核
人类的一大特点就是生命不息折腾不止，从单核折腾到了多核。
这时，假设我们想写一个程序并且要分利用多核该怎么办呢？
有的同学可能会说不是有进程吗，多开几个进程不就可以了？
听上去似乎很有道理，但是主要存在这样几个问题：
- 1）进程是需要占用内存空间的(从上一节能看到这一点)，如果多个进程基于同一个可执行程序，那么这些进程其内存区域中的内容几乎完全相同，这显然会造成内存的浪费；
- 2）计算机处理的任务可能是比较复杂的，这就涉及到了进程间通信，由于各个进程处于不同的内存地址空间，进程间通信天然需要借助操作系统，这就在增大编程难度的同时也增加了系统开销。
该怎么办呢？
6、从进程到线程
让我再来仔细的想一想这个问题，所谓进程无非就是内存中的一段区域，这段区域中保存了CPU执行的机器指令以及函数运行时的堆栈信息，要想让进程运行，就把main函数的第一条机器指令地址写入PC寄存器，这样进程就运行起来了。
进程的缺点在于只有一个入口函数，也就是main函数，因此进程中的机器指令只能被一个CPU执行，那么有没有办法让多个CPU来执行同一个进程中的机器指令呢？
聪明的你应该能想到，既然我们可以把main函数的第一条指令地址写入PC寄存器，那么其它函数和main函数又有什么区别呢？
答案是没什么区别，main函数的特殊之处无非就在于是CPU执行的第一个函数，除此之外再无特别之处，我们可以把PC寄存器指向main函数，就可以把PC寄存器指向任何一个函数。
当我们把PC寄存器指向非main函数时，线程就诞生了。
至此我们解放了思想，一个进程内可以有多个入口函数，也就是说属于同一个进程中的机器指令可以被多个CPU同时执行。
注意：这是一个和进程不同的概念，创建进程时我们需要在内存中找到一块合适的区域以装入进程，然后把CPU的PC寄存器指向main函数，也就是说进程中只有一个执行流。
但是现在不一样了，多个CPU可以在同一个屋檐下(进程占用的内存区域)同时执行属于该进程的多个入口函数，也就是说现在一个进程内可以有多个执行流了。
总是叫执行流好像有点太容易理解了，再次祭出”弄不懂原则“，起个不容易懂的名字，就叫线程吧。
这就是线程的由来。
操作系统为每个进程维护了一堆信息，用来记录进程所处的内存空间等，这堆信息记为数据集A。
同样的，操作系统也需要为线程维护一堆信息，用来记录线程的入口函数或者栈信息等，这堆数据记为数据集B。
显然数据集B要比数据A的量要少，同时不像进程，创建一个线程时无需去内存中找一段内存空间，因为线程是运行在所处进程的地址空间的，这块地址空间在程序启动时已经创建完毕，同时线程是程序在运行期间创建的（进程启动后），因此当线程开始运行的时候这块地址空间就已经存在了，线程可以直接使用。这就是为什么各种教材上提的创建线程要比创建进程快的原因（当然还有其它原因）。
值得注意的是，有了线程这个概念后，我们只需要进程开启后创建多个线程就可以让所有CPU都忙起来，这就是所谓高性能、高并发的根本所在。
很简单，只需要创建出数量合适的线程就可以了。
另外值得注意的一点是：由于各个线程共享进程的内存地址空间，因此线程之间的通信无需借助操作系统，这给程序员带来极大方便的同时也带来了无尽的麻烦，多线程遇到的多数问题都出自于线程间通信简直太方便了以至于非常容易出错。出错的根源在于CPU执行指令时根本没有线程的概念，多线程编程面临的互斥与同步问题需要程序员自己解决，关于互斥与同步问题限于篇幅就不详细展开了，大部分的操作系统资料都有详细讲解。
最后需要提醒的是：虽然前面关于线程讲解使用的图中用了多个CPU，但不是说一定要有多核才能使用多线程，在单核的情况下一样可以创建出多个线程，原因在于线程是操作系统层面的实现，和有多少个核心是没有关系的，CPU在执行机器指令时也意识不到执行的机器指令属于哪个线程。即使在只有一个CPU的情况下，操作系统也可以通过线程调度让各个线程“同时”向前推进，方法就是将CPU的时间片在各个线程之间来回分配，这样多个线程看起来就是“同时”运行了，但实际上任意时刻还是只有一个线程在运行。
7、线程与内存
在前面的讨论中我们知道了线程和CPU的关系，也就是把CPU的PC寄存器指向线程的入口函数，这样线程就可以运行起来了，这就是为什么我们创建线程时必须指定一个入口函数的原因。
无论使用任何编程语言，创建一个线程大体相同：
// 设置线程入口函数DoSomething
thread = CreateThread(DoSomething);
// 让线程运行起来
thread.Run();
那么线程和内存又有什么关联呢？
我们知道函数在被执行的时产生的数据包括：函数参数、局部变量、返回地址等信息。这些信息是保存在栈中的，线程这个概念还没有出现时进程中只有一个执行流，因此只有一个栈，这个栈的栈底就是进程的入口函数，也就是main函数。
假设main函数调用了funA，funcA又调用了funcB，如图所示：
那么有了线程以后了呢？
有了线程以后一个进程中就存在多个执行入口，即同时存在多个执行流，那么只有一个执行流的进程需要一个栈来保存运行时信息，那么很显然有多个执行流时就需要有多个栈来保存各个执行流的信息，也就是说操作系统要为每个线程在进程的地址空间中分配一个栈，即每个线程都有独属于自己的栈，能意识到这一点是极其关键的。
同时我们也可以看到，创建线程是要消耗进程内存空间的，这一点也值得注意。
8、线程的使用
现在有了线程的概念，那么接下来作为程序员我们该如何使用线程呢？
从生命周期的角度讲，线程要处理的任务有两类：长任务和短任务。
1）长任务（long-lived tasks）：
顾名思义，就是任务存活的时间很长，比如以我们常用的word为例，我们在word中编辑的文字需要保存在磁盘上，往磁盘上写数据就是一个任务，那么这时一个比较好的方法就是专门创建一个写磁盘的线程，该写线程的生命周期和word进程是一样的，只要打开word就要创建出该写线程，当用户关闭word时该线程才会被销毁，这就是长任务。
这种场景非常适合创建专用的线程来处理某些特定任务，这种情况比较简单。
有长任务，相应的就有短任务。
2）短任务（short-lived tasks）：
这个概念也很简单，那就是任务的处理时间很短，比如一次网络请求、一次数据库查询等，这种任务可以在短时间内快速处理完成。因此短任务多见于各种Server，像web server、database server、file server、mail server等，这也是互联网行业的同学最常见的场景，这种场景是我们要重点讨论的。
这种场景有两个特点：一个是任务处理所需时间短；另一个是任务数量巨大。
如果让你来处理这种类型的任务该怎么办呢？
你可能会想，这很简单啊，当server接收到一个请求后就创建一个线程来处理任务，处理完成后销毁该线程即可，So easy。
这种方法通常被称为thread-per-request，也就是说来一个请求就创建一个线程：
如果是长任务，那么这种方法可以工作的很好，但是对于大量的短任务这种方法虽然实现简单但是有缺点。
具体是以下这样的缺点：
- 1）从前几节我们能看到，线程是操作系统中的概念(这里不讨论用户态线程实现、协程之类)，因此创建线程天然需要借助操作系统来完成，操作系统创建和销毁线程是需要消耗时间的；
- 2）每个线程需要有自己独立的栈，因此当创建大量线程时会消耗过多的内存等系统资源。
这就好比你是一个工厂老板（想想都很开心有没有），手里有很多订单，每来一批订单就要招一批工人，生产的产品非常简单，工人们很快就能处理完，处理完这批订单后就把这些千辛万苦招过来的工人辞退掉，当有新的订单时你再千辛万苦的招一遍工人，干活儿5分钟招人10小时，如果你不是励志要让企业倒闭的话大概是不会这么做到的。
因此一个更好的策略就是招一批人后就地养着，有订单时处理订单，没有订单时大家可以闲呆着。
这就是线程池的由来。
9、从多线程到线程池
线程池的概念是非常简单的，无非就是创建一批线程，之后就不再释放了，有任务就提交给这些线程处理，因此无需频繁的创建、销毁线程，同时由于线程池中的线程个数通常是固定的，也不会消耗过多的内存，因此这里的思想就是复用、可控。
10、线程池是如何工作的
可能有的同学会问，该怎么给线程池提交任务呢？这些任务又是怎么给到线程池中线程呢？
很显然，数据结构中的队列天然适合这种场景，提交任务的就是生产者，消费任务的线程就是消费者，实际上这就是经典的生产者-消费者问题。
现在你应该知道为什么操作系统课程要讲、面试要问这个问题了吧，因为如果你对生产者-消费者问题不理解的话，本质上你是无法正确的写出线程池的。
限于篇幅在这里不打算详细的讲解生产者消费者问题，参考操作系统相关资料就能获取答案。这里我打算讲一讲一般提交给线程池的任务是什么样子的。
一般来说提交给线程池的任务包含两部分：
伪码描述一下：
struct task {
void* data; // 任务所携带的数据
handler handle; // 处理数据的方法
}
（注意：你也可以把代码中的struct理解成class，也就是对象)
线程池中的线程会阻塞在队列上，当生产者向队列中写入数据后，线程池中的某个线程会被唤醒，该线程从队列中取出上述结构体(或者对象)，以结构体(或者对象)中的数据为参数并调用处理函数。
伪码如下：
while(true) {
struct task = GetFromQueue(); // 从队列中取出数据
task->handle(task->data); // 处理数据
}
以上就是线程池最核心的部分。
理解这些你就能明白线程池是如何工作的了。
11、线程池中线程的数量
现在线程池有了，那么线程池中线程的数量该是多少呢？
在接着往下看前先自己想一想这个问题。如果你能看到这里说明还没有睡着。
要知道线程池的线程过少就不能充分利用CPU，线程创建的过多反而会造成系统性能下降，内存占用过多，线程切换造成的消耗等等。因此线程的数量既不能太多也不能太少，那到底该是多少呢？
回答这个问题，你需要知道线程池处理的任务有哪几类，有的同学可能会说你不是说有两类吗？长任务和短任务，这个是从生命周期的角度来看的，那么从处理任务所需要的资源角度看也有两种类型，这就是没事儿找抽型。。。啊不，是CPU密集型和I/O密集型。
1）CPU密集型：
所谓CPU密集型就是说处理任务不需要依赖外部I/O，比如科学计算、矩阵运算等等。在这种情况下只要线程的数量和核数基本相同就可以充分利用CPU资源。
2）I/O密集型：
这一类任务可能计算部分所占用时间不多，大部分时间都用在了比如磁盘I/O、网络I/O等。
这种情况下就稍微复杂一些了，你需要利用性能测试工具评估出用在I/O等待上的时间，这里记为WT(wait time)，以及CPU计算所需要的时间，这里记为CT（computing time），那么对于一个N核的系统，合适的线程数大概是 N * (1 + WT/CT) ，假设I/O等待时间和计算时间相同，那么你大概需要2N个线程才能充分利用CPU资源，注意这只是一个理论值，具体设置多少需要根据真实的业务场景进行测试。
当然充分利用CPU不是唯一需要考虑的点，随着线程数量的增多，内存占用、系统调度、打开的文件数量、打开的socker数量以及打开的数据库链接等等是都需要考虑的。
因此这里没有万能公式，要具体情况具体分析。
12、线程池不是万能的
线程池仅仅是多线程的一种使用形式，因此多线程面临的问题线程池同样不能避免，像死锁问题、race condition问题等等，关于这一部分同样可以参考操作系统相关资料就能得到答案，所以基础很重要呀老铁们。
13、线程池使用的最佳实践
线程池是程序员手中强大的武器，互联网公司的各个server上几乎都能见到线程池的身影。
但使用线程池前你需要考虑：
- 1）充分理解你的任务，是长任务还是短任务、是CPU密集型还是I/O密集型，如果两种都有，那么一种可能更好的办法是把这两类任务放到不同的线程池中，这样也许可以更好的确定线程数量；
- 2）如果线程池中的任务有I/O操作，那么务必对此任务设置超时，否则处理该任务的线程可能会一直阻塞下去；
- 3）线程池中的任务最好不要同步等待其它任务的结果。
14、本文小结
本文我们从CPU开始一路来到常用的线程池，从底层到上层、从硬件到软件。
注意：这里通篇没有出现任何特定的编程语言，线程不是语言层面的概念（依然不考虑用户态线程），但是当你真正理解了线程后，相信你可以在任何一门语言下用好多线程，你需要理解的是道，此后才是术。
希望这篇文章对大家理解线程以及线程池有所帮助。
接下的一篇将是与线程池密切配合实现高性能、高并发的又一关键技术《从根上理解高性能、高并发(二)：深入操作系统，理解I/O与零拷贝技术》，敬请期待。
附录：更多高性能、高并发方面的文章
[1] IM方面的高性能、高并发文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
>> 更多同类文章 ……
[2] 其它高性能、高并发设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》
《美团技术分享：深度解密美团的分布式ID生成算法》
《12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)》
>> 更多同类文章 ……
（本文已同步发布于：http://www.52im.net/thread-3272-1-1.html）