自己写cache server之网络框架处理——对比mysql、Oracle（上）

Jack：hi，淫龙。急救。

我：周末了，在碎懒觉。

Jack：老板让我自己写个高性能的Cache数据库。你知道的，这个有多难。一时半会儿哪写得出来。

我：慢慢写吧。这玩意儿一时半会儿写不出来的。

Jack：哎~太蛋疼了。你有什么好的建议吗？

我：你说说这个server大概要面对什么样的业务吧。然后咱们再聊聊。

Jack：1、这个server要定制（所以不能把市面上的那些memcache啥的直接搬过来）。

2、这个server面对读写压力为10:1的场景。

3、典型的互联网应用场景。

4、机器有16颗CPU，以后还可能增加。

6、内存80G、磁盘1T。

我：我操。这个不是开玩笑的。

Jack：老板也不是开玩笑的。他说要是半年没个交代，就直接卷铺盖走人。

我：恩。明白了。面对这样的需求，你首先需要思考，这个server的网络框架是如何设计的。这是Cache Server设计的总纲。后面的内存管理、文件存储都是根据这个模型设计出来的。

Jack：好的。由于有16颗CPU，必然会用到多进程/多线程。

我：是的。但是在设计Cache Server时，你必须要考虑到多进程、多线程可能面临的问题。

Jack：举个例子呢。

我：例如，Oracle的dedicated采用了多进程的模型，mysql采用了多线程模型，他们面临的问题就完全不同。

Oracle的网络事件框架，出自《Expert Oracle Database Architecture》

Jack：不是太明白。

我：Oracle采用了多进程设计模型。而数据库（包括cache server）必然面临数据同步与互斥的问题。多进程时，进程间的内存区域是隔开的（参见我将会写的“Linux内核源代码分析——进程的领地之内存”）。如何进行多进程间数据同步呢？在同步的手段设计好之后，如何进行互斥呢？

Jack：明白了。那Oracle是如何解决这个问题的呢？

我：Oracle采用了共享内存。通过类似于shmget这样的api从操作系统里申请了一大块共享内存然后意淫出一个概念，就是俗称的SGA。

Jack：明白了。那mysql是如何设计网络事件框架的呢？

我：mysql采用了one request one loop的模型。简单地说，就是多线程的概念。

Jack：那这个模型有什么难点吗？

我：难点在于多线程间的同步。因为在同一个进程里，线程间可以共享一些数据。但是如何做到互斥，就比较难，尤其是具备transaction的关系型数据库。

Jack：mysql是如何解决这个问题的呢？

我：mysql解决这个问题，主要采用了mutex。

Jack：这个我知道，Oracle还有latch、mutex的概念。

我：这里的mutex和你所说的那个mutex应该不是同一个概念。这里的mutex是Linux内核提供的api。而你所说的那个mutex应该是在这之上的衍生品（？），也就是说，Oracle里的mutex是Oracle的设计人员、文档编写者意淫出来的。

附上Steve Adams关于latch的一些认识。

其中加粗的部分描述了操作系统内核的spinlock与Oracle的latch之间关系。不过这段话太过泛泛，关键点一笔带过，没有（？）深入下去。

The alternative to spinning is to relinquish the CPU and allow another process to

use it. At first glance, this may seem like a good idea. However, for a CPU to stop

executing one process and begin executing another, it must perform a context

switch . That is, it must save the context of the first process, determine which

process to schedule next, and then resume the context of the next process. The

context of a process is essentially a set of CPU register values that describes the

exact state of the process.

The implementation of context switches is highly machine dependent. In fact, it

is typically written in assembly language. System vendors make every effort to

minimize the size of the context data and optimize context switching by using

tricks such as remapping memory addresses rather than copying data.

Nevertheless, context switching remains an expensive operation because various

kernel data structures have to be searched and updated. Access to these

structures is protected by spinlocks, which are the equivalent of latches for the

operating system. On a large and busy system, context switching normally

consumes between 1% and 3% of CPU time. So if a context switch can be avoided

by spinning briefly, then some CPU time can be saved, and the waiting time to

obtain the latch can be minimized. For this reason, spinning briefly is normally

preferable to relinquishing the CPU immediately.