大多数业务场景需要使用可靠性消息，Kafka在高可靠场景下的性能表现到底如何呢？
本文的压测结果是消息大小100字节、开启和不开启batch，producer的QPS分别可以达到3.6W和24.8W。
在高可靠场景下，微信开源PhxQueue vs Kafka的性能：消息大小为10字节、开启和不开启batch，Kafka的producer的QPS分别可以达到180W/S和9W/S
压测结果用于评估是否可以用于实际的业务场景，所以压测场景并未穷举多种message.size、batch.size以及partitions.size
最近线上应用出现了一个诡异问题，在访问量无明显增长、线上未做任何变更（代码发布和DB操作）的情况下，某个业务子系统突然出现大量的业务接口超时，MySQL性能急剧下降，系统不可用。
当时观察到的主要异常现象包括MySQL出现大量的慢查询、MySQL服务器的system cpu time飙高、MySQL的性能急剧下降、业务接口响应时间飙高、业务系统大量出现获取不到DB connection的异常日志等现象。当时的主要信息如下。
通常限流主要是限制并发数以及QPS，从而避免异常流量对系统的冲击；
并发数和QPS是紧密相关的，可以参考Little’s Law(律特法则)：L = λW （proven 1961）
一个排队系统在稳定状态下，在系统里面的个体的数量的平均值 L， 等于
平均个体到达率λ （单位是λ个每单位时间）乘以 个体的平均逗留时间W
数学定理（严格的数学推理，非经验公式）
排队论的理论
UPATE: 内容已更新到Elasticsearch v5.6
内存对Elasticsearch而言，非常重要，因为它为了提升性能使用了大量的in-memory数据结构。
官网推荐给Elasticsearch分配的内存不能超过32GB(小于32GB时会启用compressed oops，节省很多内存)
并且还必须是小于物理内存的50%，以便为Lucene利用Cached Memory提供更多的剩余内存。
Elasticsearch内部是如何使用这些内存的呢？下面这张图说明了Elasticsearch和Lucene对内存的使用情况。
Kafka官网给我们提供了一些很好的最佳实践，但是内容还不够详实。
所以这篇文章整理了各大公司Kafka最佳实践的最新资料，为使用Kafka提供参考。
UPDATE:内容更新如下
《Software Architecture Patterns》（PDF）这本书的内容短小精悍、通俗易懂，举的例子相对简单，偏重理论。
根据我对这本书的理解以及在架构方面的实践总结形成了这篇文章，重点讲讲这些模式的具体实践。
从这本涉及到的技术概念可以看出，作者偏重于企业级应用的架构。
比如文中提到的：Spring Integration、Apache Camel和Mule ESB ，他们都是主流的开源EIP框架，这些框架并不适用于互联网公司，相对于互联网的业务逻辑，这些框架太重，不是轻量级的框架。还提到了BPEL引擎，比如Apache ODE和jBPM。
EIP: Enterprise Integration Patterns 企业集成模式，涵盖了40+种模式
本文涉及到分层架构、事件驱动架构、微内核架构以及微服务架构。书中最后描述的基于空间的架构（基于云的架构），因为实际应用中未涉及到，所以本文不作描述。
