RocketMQ作为消息中间件，经常会被用来和其他消息中间件做比较，比对rabbitmq, kafka... 但个人觉得它一直对标的，都是kafka。因为它们面对的场景往往都是超高并发，超高性能要求的场景。
所以，有必要深挖下其实现高性能，高并发的原因。实际上，这是非常大的话题，我这里也不打算一口吃个大胖子。我会给出个大概答案，然后我们再深入挖掘其中部分实现。如题所述。
1. 高性能高并发系统的底层技能概述
我不打算单讲rocketmq到底是如何实现高性能高并发的，因为实际上的底层原则都是差不多的。rocketmq不过是其中的一个实现者而已。
那么，要想实现高性能高并发，大概需要怎么做的呢？本质上讲，我们的系统服务能利用的东西并不多，CPU、内存、磁盘、网络、硬件特性。。。 当然了，还有一个非常重要的东西，就是我们基本都是在做应用层服务，所以我们的能力往往必须依托于操作系统提供的服务，由这些服务去更好地利用底层硬件的东西。好吧，显得逼格好像有点高了，实际上就是一个系统API调用。
接下来，我们从每个小点出发，来看看我们如何做到高性能高并发：
第一个：CPU。可以说，CPU代表了单机的极限。如果能够做有效利用CPU, 使其随时可保证在80%以上的使用率，那么你这个服务绝对够牛逼了（注意不是导致疯狂GC的那种利用率哦）。那么，我们如何做到高效利用CPU呢？有些应用天然就是CPU型的，比如提供一些做大数的运算服务，天生就需要大量CPU运算。而其他的很多的IO型的应用，则CPU往往不会太高，或者说我们应该往高了的方向优化。
第二个：内存。内存是一个非常宝贵的资源，因为内存的调度速度非常快。如果一个应用的业务处理都是基于内存的，那么这个应用基本上就会超级强悍。大部分情况下，越大的内存往往也能提供越高的性能，比如ES的搜索服务，要想性能好必需有足够内存。当然了，内存除了使用起来非常方便之外，它还有一个重要的工作，就是内存的回收。当然，这部分工作一般都会被编程屏蔽掉，因为它实在太难了。我们一般只需按照语言特性，合理的处理对象即可。另外，我们可以一些可能需要从外部设备读入的数据，加载到内存中长期使用，这将是一件非常重要的优化动作。如何维护好数据一致性与安全性和准确性，是这类工作的重点。
第三个：磁盘。内存虽好，但却不常有。内存往往意味着大小受限。而与之对应的就是磁盘，磁盘则往往意味空间非常大，数据永久存储安全。磁盘基本上就代表了单机的存储极限，但也同时限制了并发能力。
第四个：网络。也许这个名词不太合适，但却是因为网络才发生了变化。如果说前面讲的都是单机的极限性能，那么，网络就会带来分布式系统的极限性能。一个庞大的系统，一定是分布式的，因此必然会使用到网络这个设备。但我们一般不会在这上面节省多少东西，我们能做的，也许就是简单的压缩下文件数据而已。更多的，也许我们只是申请更大的带宽，或者开辟新的布线，以满足系统的需要。在网络这一环境，如何更好地组织网络设备，是重中之重，而这往往又回到了上面三个话题之一了。
最后，排除上面几个硬技能，还有一个也是非常重要的技能：那就是算法，没有好的算法，再多的优化可能也只是杯水车薪。（当然了我们大部分情况下是无需高级算法的，因为大部分时间，我们只是大自然的搬运工）
2. 高性能高并发操作系统api列举
前面说的，更多是理论上讲如何形成牛逼的应用服务。但我们又没那能力去搞操作系统的东西，所以也只能想想而已。那么说到底，我们能做什么呢？所谓工欲善其事，必先利其器。所谓利器，也就是看看操作系统提供什么样的底层API 。
我这里就稍微列几个吧（我也就知道这么些了）：
epoll系列: IO多路复用技术，高并发高性能网络应用必备。大致作用就是使极少数的线程，高效地管理大量io事件，通知应用等。大概的接口有: epoll_create(), epoll_ctl(), epoll_wait();
pagecache系列: 操作系统页缓存，高效写文件必备。大致作用就是保留部分磁盘数据在内存中，以便应用想读取或者磁盘数据数据时能够非常快速的响应。相关接口如: read(), write(), readpage(), writepage(), sync(), fsync().
mmap系列: 内存映射。可以将文件映射到内存中，用户写数据时直接向该内存缓冲区写数据，即可达到写磁盘的作用了，从而提高写入性能。接口如: mmap(), munmap();
directio系列: 直接io操作，避免用户态数据到内核态数据的相互copy, 节省cpu和内存占用。
CAS系列: 高效安全锁实现。相关接口: cmpxchg() 。