作者：朱政科
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
HikariCP数据库连接池实战试读：
前言
第一篇 准备篇第1章 阿里中间件实战，第一个案例1.1 物联网MQTT单机压测130万参数调优1.2 阿里中间件TCP四次挥手性能调优实战1.2.1 亿级消息网关Rowan架构1.2.2 人脸识别服务：异曲同工的架构1.2.3 “双十一大促”全链路压测发现TCP问题1.2.4 Linux内核网络参数调优1.2.5 Linux TCP参数调优1.2.6 一行代码大幅提升QPS1.3 技术驱动业务，结果未导向1.4 本章小结第2章 数据库连接池江湖2.1 为什么使用数据库连接池2.2 数据库连接池原理2.3 数据库连接池百晓生《兵器谱》2.3.1 c3p02.3.2 Proxool2.3.3 XAPool2.3.4 DBCP2.3.5 Tomcat JDBC Pool2.3.6 BoneCP2.3.7 Druid2.4 主流数据库连接池对比2.4.1 性能对比2.4.2 代码复杂度2.4.3 功能对比2.4.4 数据库中断2.5 本章小结第3章 初识HikariCP3.1 Hikari背景、特色及前景3.2 SpringBoot数据库连接池加载顺序剖析3.3 SpringBoot整合HikariCP实战3.3.1 Spring Initializr3.3.2 添加HikariCP依赖3.3.3 JdbcTemplate3.3.4 Database Initialization3.3.5 启动运行3.4 本章小结
第二篇 基础篇第4章 HikariCP参数配置4.1 校时4.2 HikariCP配置手册4.2.1 必需配置4.2.2 非必需配置4.3 HikariCP连接池配置多大合适4.4 Fixed Pool Design思想4.5 MySQL高性能配置4.6 Hibernate配置4.7 JNDI配置4.3 本章小结第5章 HikariCP与JDBC5.1 HikariCP JDBC Logging5.2 JDBC5.2.1 JDBC定义5.2.2 JDBC实战案例5.2.3 JDBC剖析5.2.4 PreparedStatement和Statement5.3 JDBC与SPI5.3.1 SPI简介5.3.2 SPI实战案例5.3.3 JDBC的SPI机制5.3.4 SPI高级实战：基于Dubbo的分布式日志链路TraceID追踪5.4 拓展：线程池技术5.4.1 MySQL线程池简介5.4.2 MySQL线程池技术内幕5.4.3 MySQL线程池实战5.5 本章小结
第三篇 原理篇第6章 HikariCP性能揭秘6.1 华山论剑6.2 第三方测评6.2.1 环境配置6.2.2 获取关闭连接性能测试6.2.3 查询一条语句性能测试6.2.4 psCache性能对比6.2.5 测试结论6.3 HikariCP为什么这么快6.3.1 精简字节码6.3.2 FastList6.3.3 ConcurrentBag6.4 本章小结第7章 HikariCP连接原理7.1 获取连接7.2 归还连接7.3 关闭连接7.4 生成连接7.5 扩展阅读：DCL为什么要加volatile7.6 扩展阅读：Log4j2为何性能优秀7.7 本章小结第8章 HikariCP参数源码解析8.1 SpringBoot 2.X HikariCP参数加载原理8.2 allowPoolSuspension8.3 validationTimeout8.4 leakDetectionThreshold8.5 本章小结第9章 HikariCP动态代理与字节码技术9.1 HikariCP字节码工程9.1.1 HikariCP的字节码技术9.1.2 代理技术原理9.1.3 HikariCP JIT方法内联优化9.2 JMH基准测试9.2.1 JMH常用注解9.2.2 JMH实战案例Orika9.3 本章小结
第四篇 实践篇第10章 HikariCP监控实战10.1 监控体系层次10.2 为什么需要数据库连接池监控10.3 HikariCP监控指标10.3.1 hikaricp_pending_threads10.3.2 hikaricp_connection_acquired_nanos10.3.3 hikaricp_idle_connections10.3.4 hikaricp_active_connections10.3.5 hikaricp_connection_usage_millis10.3.6 hikaricp_connection_timeout_total10.3.7 hikaricp_connection_creation_millis10.4 HikariCP监控指标实战10.4.1 连接风暴10.4.2 慢SQL10.4.3 监控指标与参数配置10.5 SpringBoot 2.0暴露HikariCP Metrics10.6 SpringBoot 2.0监控HikariCP JMX10.7 微服务架构下的监控平台选型10.8 本章小结第11章 从HikariCP Metrics谈微服务监控架构实战11.2 HikariCP Metrics11.3 Micrometer11.4 SpringBoot 2.x自定义埋点实战11.4.1 引入依赖11.4.2 配置application.properties11.4.3 注册Metrics11.4.4 支付接口埋点统计总次数11.4.5 查看指标数据11.5 SpringBoot 2.x集成Micrometer源码解析11.6 SpringBoot 1.5.x自定义埋点实战11.6.1 引入Micrometer依赖11.6.2 创建Bean并注册Metrics指标11.6.3 在Controller中进行支付业务埋点11.7 监控架构重点11.7.1 Prometheus11.7.2 Grafana11.8 本章小结第12章 HikariCP扩展技术12.1 Flexy-Pool12.2 Apache ShardingSphere12.3 自研集成HikariCP和Sharding-JDBC数据库中间件12.4 时钟回拨12.5 本章小结第13章 HikariCP常见问题13.1 HikariCP故障分析技巧13.2 leakDetectionThreshold参数解决Spark/Scala连接池泄
漏13.3 详解JDBC超时13.4 快速恢复13.5 Oracle Connection Reset问题13.6 HikariCP关闭连接的5种情况13.7 如何获取HikariDataSource的active connection13.8 如何对HikariCP配置文件中的服务器名、用户名、密
码加密13.9 HikariCP神奇的配置dataSourceProperties13.10 如何获取HikariCP连接池中的原始连接13.11 HikariCP并不是万能工具13.12 本章小结第14章 HikariCP诡案实录14.1 问题描述14.2 Brett经典回答14.3 另一个类似的案例14.4 分析问题14.5 解决问题14.6 本章小结赞誉
无论是业务应用，还是数据库中间层研发领域的工程师，数据库连接池都是一个绕不开的话题。数据库连接池就像空气一样重要且无处不在，但又设计精妙，使得开发者无需直接感受到它的存在。
经历这如此漫长的发展之后，新一代的数据库连接池翘楚，HikariCP已经受到越来越广泛的关注，并且逐渐成为应用开发的首选。我主导的开源项目Apache ShardingSphere也因为它极致的性能而被采用为默认的数据库连接池。
一直以来，业界都缺少一本关于HikariCP的专业书籍。本作的出现，终于弥补了这方面的缺失，希望读者能够和我一样，通过阅读本作更加全面的了解数据库连接池的运行原理和实现机制。张亮京东数科数据研发负责人Apache ShardingSphere发起人&PPMC《未来架构——从服务化到云原生》作者
连接池作为应用系统中最常用，也是压力最大的组件库之一，对整个系统的稳定起到了至关重要的作用。
APM的监控案例中，大量的性能和数据库访问、连接池使用有直接的联系，也是系统性能的TOP 10根源之一。
HikariCP项目作为一个优秀的开源连接池项目，对它的深入学习和理解会很好的保证项目功能以及性能稳定。
通过本书，读者能够更好的了解HikariCP连接池的原理、配置和使用方法，学习到实用的工程实践经验。吴晟tetrate.io founding engineer.Apache SkyWalking创始人&VPApache ShardingSphere原型作者&PPMC成员Apache Incubator PMC成员
在数据库的OLTP型的应用的特点往往是并发请求高，每秒处理的请求数多，单次请求的处理时间短。基于这些特征，通常客户端与数据库的连接通常建议使用连接池。
以PostgreSQL或Oracle数据库为例在没有连接池的情况下，用户每次请求前都要和数据库建立连接，数据库要检查来源客户端是否满足ACL列表需求，FORK backend process，使用配置好的认证方法与客户端进行认证。
通常使用连接池的情况下QPS可以达到百万级，而不使用连接池的情况下，QPS可能只有不到1万。可想而知在OLTP系统中连接池的重要性。
市面上开源的连接池很多，不同连接池有不同的特色，例如Druid不仅仅是个连接池，还支持了SQL请求的监控统计、SQL防火墙的能力。
HikariCP则是业界非常有名的一款以性能著称的连接池，感谢作者给我们带来了一本全面解析HikariCP的好书。本书对HikariCP的历史、原理、应用实践进行了非常详细的介绍，相信通过本书可以对HikariCP以及连接池技术有非常深刻的了解。周中正（德哥digoal）PostgreSQL社区成员
数据是互联网的核心价值，一款好用且高效的数据库及相关中间件则是这份核心价值的重要保障，也是值得技术工程师们深入学习研究的对象。始于2013年的HikariCP，在众多连接池中间件项目中，脱颖而出，得到越来越多互联网公司及从业人员的青睐。本书作者对HikariCP的各种技术原理和实现细节有着深入的理解掌握，同时结合上工作中碰到的Linux内核、TCP网络知识及性能调优实例经验，内容深入浅出，行文也不乏风趣幽默，不光是一本系统性介绍HikariCP的宝典，更是借此打开中间件研发大门的最佳通道。希望本书的读者们，无论是初学者，还是有进阶提升的需求，都能仔细研读并从中汲取到养分。张聪前阿里巴巴、滴滴出行架构师杭州比智科技有限公司（奇点云）应用研发总监，首席架构师
数据库连接池是程序员接触最多但又最容易忽略的重要技术组件，并不是随意找个数据库池连接池就可以让应用发挥最大功效，我们需要从性能、扩展性、连接池管理、监控以及社区的活跃度等进行甄别。本书不仅对市面上常见的一些连接池组件进行了全方位比较和分析，还重点以实战的角度深入的介绍了高性能HikariCP连接池的使用、原理与维护。政科是我认识多年的好友，他在技术上面的严谨执着和一丝不苟，传承的就是一种工匠精神，相信读者通过本书定能受益匪浅。程超《高可用可伸缩微服务架构》联合作者《深入分布式缓存》联合作者
作者以HikariCP入手，串起来点、线、面，行文生动，内容翔实丰满。性能是第一个案例的入手点，并比较了各大数据库连接池，最后在HikariCP配置、性能揭秘、监控等多方面展开描述。本书较好的诠释了从原理到实践这一思想，对于使用HikariCP的朋友可以成为居家旅行必备，对于了解整体池化技术或者性能优化的朋友，亦有他山之石之效。于君泽《深入分布式缓存》联合作者公众号《技术琐话》运营者
HikariCP作为Spring Boot 2.0的默认数据库连接池，从不为人知到一日爆红。乘着Spring Boot这艘大船，必定成为java开发的主流数据库连接池。《HikariCP实战》通过庖丁解牛式的技术分解，对JDBC和数据库连接池涉及到的技术实现细节及一些常见问题进行了梳理。通过阅读本书可以对Java数据库开发技术有一个更深入、系统的掌握。
构建一个高性能的网络应用需要从网络协议层、应用协议层进行全链路的推敲，另外连接池设计和线程工作模型的设计是关键点。数据库连接池麻雀虽小五脏俱全，通过《HikariCP实战》学习一个优秀的数据库连接池产品及其相关的技术，从而掌握高性能网络开发相关的部分技术是一个非常好的学习方式。
随着开源软件的成熟，作为淘宝去IOE后处理海量数据请求的最重要技术-分库分表技术不再是大型互联网公司的专享技术。如果你正遇到大数据量导致的数据库性能瓶颈，或者希望到大型互联网公司去工作，“自研集成HikariCP和Sharding-JDBC数据库中间件”这一节请了解一下。
注：淘宝去IOE就是去掉IBM的小型机、Oracle数据库、EMC存储设备，代之在开源软件基础上开发的系统。《HikariCP连接池实战》不仅仅是告诉读者如何使用HikariCP数据库连接池，而是一本围绕数据库连接池相关技术展开的高性能Java开发技术实战书，任何一个对技术有好奇心的Java开发者都可以从本书收获良多。杨俊阿里技术专家2014年阿里中间件性能挑战赛JAVA组第二名
资源的复用能够提升资源利用率，降低成本，其中数据库连接池便是对数据库连接资源进行复用。对数据库连接池原理的了解及使用，基本上已经成了软件从业人员必备技能。目前市面上已经有很多数据库连接池的组件，在数据库连接池红海市场中，HikariCP作为后起之秀能够实现浴血突围，有非常多独到之处。本书全面描述了HikariCP的独到设计，在软件的设计和性能优化等方面会给你打开一扇新的窗口。何涛网联架构师
第一次看到这本书名时，就在想连接池有啥可讲的，我天天都在使用，而当我翻开书阅读时就被作者讲述的阿里中间件实战经验深深吸引了，个个都是鲜活的高并发案例，而支撑这些高并发背后最有挑战的就是数据库连接池性能。作者通过Linux内核网络参数调优和TCP原理入手，再通过JDBC剖析、SPI实战、动态代理与字节码技术等，由浅入深地介绍HikariCP的“简单、极致、可靠”的设计哲学。杨彪《分布式服务架构：原理、设计与实战》作者《可伸缩服务架构：框架与中间件》作者原蚂蚁金服专家，高级架构师
前言
为什么要写这本书我在年少时也曾做过许多梦，有些梦实现了，有些梦忘却了，这些梦大多都是我一个人的梦。2017年我开始从事数据库连接池中间件的研发和架构工作，并在公司内部写了一系列原创的数据库连接池HikariCP源码解析和实战的文章。在老板张聪的建议下，我申请了微信公众号并坚持分享技术，公众号的初心是：“写的内容要有人阅读，这样才会引起互动交流；有朋友就不会觉得孤独，而且互相的探讨也有助于自身提高”。
也许是注定的安排，我从事的底层数据库中间件采用了HikariCP这款数据库连接池，这让我和HikariCP结下了不解之缘。非常幸运的是，在长达近一年的时间内，每天都有大量的业务开发人员向我咨询数据库连接池的各项问题，最多的时候可以达到十多位同学排队咨询问题，颇有老中医开堂坐诊的感觉。我是一个细心的人，大家的疑问和最后的解决方式都会一一记录下来，我也会协助网友以及其他公司的技术人员分析定位数据库连接池问题，帮助他们的项目顺利上线我也同样可以分享喜悦，这段经历是我技术之路上宝贵的财富。
我毕业于哈工大，哈工大的校训是“规格严格、功夫到家”，母校影响着我的做事风格，我是一个追求极致的人。但每当我协助业务开发排查问题时，却常常发现糟糕的事情。比如很多业务项目里充斥着HikariCP、Druid、BoneCP、c3p0、Tomcat JDBC等多种数据库连接池依赖项，而开发人员却并不知道自己究竟使用的是哪款数据库连接池，而将依赖做到精简是中间件岗位最基本的素养，美国童子军也有一条“让营地比你来时更干净”的军规，这也是《Clean Code》这本经典书强烈建议的；再比如，我发现很多业务开发同学咨询的问题如果总结下来是可以分门别类的，但是部分人解决了问题并不会分享、传播、传承，进而造成其他人接二连三的因为类似的问题再度陷入费时费力的排查之中；再比如，很多技术人员在学习使用数据库连接池之后想对更深入的技术进行探索，然而市面上却没有任何一本体系、深入地介绍数据库连接池的书，导致他们遗憾得继续投入到其他项目中从而没有完成深入了解数据库连接池的梦。因此，我决定著书立说，这是全中国抑或是全世界第一本介绍数据库连接池的书，由于这本书中凝结的更多的是我多年的实践经验、我对于社区数据库连接池上千条问题讨论的研读等等，所以这本书称之为《HikariCP实战》。
HikariCP日语意思是光，代表了极致。极致无处不在，极致可以小到一次代码提交，可以大到整个研发流程；极致可以小到一行JDK底层代码，也可以大到整个电商系统架构；极致可以运用在技术选型，也可以运用在团队管理。极致也是分场景的，有些是大规模高并发的极致要求，有些原则上不到一定的数量级轻易勿用。极致的追求，不仅仅需要对基础技术原理有足够深入了解，还需要配套的中间件支持，相关的业务协助改造。极致之路，没有银弹，不要想一招毙命，一口吃成个胖子，而是要审时度势，根据当前的现状来裁定。在和HikariCP打交道的期间，我发现这是数据库连接池届一款以追求极致为追求的艺术作品。不论是从相关文献资料、问题讨论、源码更新，还是从HikariCP多年来不辞辛劳一步一个脚印的社区贡献，我都能深深感受到HikariCP在极致之路上一次又一次得超越自我，以狼心追求卓越并面对未来的抉择。
光不但是极致，更是希望。这些年，尤其是写这本书的期间，我承受了不少的委屈，也遭遇了很多的坎坷，经历了生离，也经历了死别。然而我坚持将自己的梦实现，希望能活成一束光，能够温暖到别人能够照亮别人，这才是真正的正能量。《HikariCP实战》，是我的孩子，也是我梦想的实现，但我希望它不再是属于我一个人的梦，更希望能够将HikariCP的光亮照进每一名读者心中，最后送大家一段话：“在一无所有时，也请坚持做一名追光者，愿大家都能找到自己内心深处的光，接近它成为它，去发光去发亮，成为别人眼中的和照亮别人的光，用更亮的光芒照亮世界的每一个角落。你就是太阳，蒸发了彷徨，有你的地方就是天堂。”读者对象
本书适合所有Java程序员阅读，尤其适合以下读者：
·Java初中级开发者。
·系统架构师。
·中间件开发者。
·Java多线程、并发开发者。
·使用HikariCP参与工作流程的公司与集体。
·开设Java相关课程的大专院校。
·其他对数据库连接池技术感兴趣的人员。本书特色
本书是国内抑或是全球第一本系统介绍数据库连接池HikariCP的书，在本书写作的过程中，我尽量避免让这本书成为“代码书”或者“概念书”，全部用自己的实战经验和大量文献涉猎将其凝结为一本高内涵高价值的实战书籍。这本书准确的说写了两年的时间，第一年是我数据库连接池的实践工作以及零散的文字记录，第二年是较为体系化的书籍的梳理成册。本书的目录结构也经过了好几个版本的迭代修改，旨在让读者用最短的时间循序渐进的学完相关知识点；本书的篇幅也做过很多的压缩、删减，聚焦核心内容，像“瑞士军刀”一样短小锋利，可以帮助读者快速学习并解决问题。
本书以阿里大型消息中间件的无池化TCP调优开篇，这也是我在阿里晋升答辩的内容之一，在扩展性能调优知识的同时顺带引出Java平台下性能调优的利器——数据库连接池，这样的开头可以让读者真真切切感受到数据库连接池出现的必要性。接着，从数据库连接池出现的背景、原因入手，循序渐进的一步步为大家盘点了主流的数据库连接池并进行了对比，这也弥补了市面上并没有一本书体系收录介绍各种数据库连接池的遗憾。
当然，这还只是“前戏”，本书最精彩的部分在于对数据库连接池已经有了基本的认识之后，我们将一起剖析HikariCP这款数据库连接池的设计理念和原理，并对其重点功能和模块逐一进行讲解。在分析之余，这本书还会将HikariCP的关联技术、具体实战、扩展内容等等进行补充说明，旨在帮助读者能够举一反三、触类旁通。本书最后以一个疑难杂症问题为例，通过排查问题，帮助大家一起对HikariCP的相关内容回顾和展望，以求融会贯通、温故而知新。如何阅读本书
本书分为四大部分：
第一部分为准备篇，以阿里连接池极致优化案例引入，帮助读者了解数据库连接池的背景、原理，并全面了解主流的数据库连接池，包含本书的主角HikariCP。
第二部分为基础篇，着重讲解HikariCP参数配置、JDBC等核心模块。这些内容都是HikariCP重中之重的基础，除了原理性介绍以外，为了帮助读者夯实数据库连接池的基础，本书还特地对技术细节、设计理念、实战扩展等方面进行了小知识点的补充。
第三部分为原理篇，首先，全方位的剖析了HikariCP性能极致的原因，这些都会成为读者面试、工作中的谈资；其次，从连接原理、参数原理、动态代理与字节码技术等三个维度作为切入口，分别对HikariCP进行了源码级别的解析，这样全方位的剖析不同于单视角的源码解析，更能将HikariCP的原理立体化的展示在读者面前。
第四部分为实战篇，这是本书精华的部分。HikariCP的监控、扩展技术、常见问题等都是读者工作中较为迫切了解到、使用到的知识点，这些内容大多来自我实战经验的积累及大量文献资料的收集整理，内容包罗万象、精妙绝伦。本部分可以独立阅读，做为案头的工具书使用。勘误和支持
由于作者的水平有限，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。为此，我再在GitHub网站上专门新建了一个issue项目（https://github.com/CharlesMaster/Hikari/issues）。你可以将书中的错误、疑问、改进建议以GitHub Issue的形式发布在Bug勘误表页面中，我将尽量在线上为读者提供最满意的解答。当然，更希望大家可以通过issue关于HikariCP展开讨论，互相切磋和共同成长。如果你有更多的宝贵意见，也欢迎发送邮件至邮箱just_love_zzk@126.com，期待能够得到你们的真挚反馈。致谢
首先要感谢伟大的HikariCP作者Brett Wooldridge，他开创了一款影响我整个人生的软件。
感谢Apache ShardingSphere PPMC张亮、Apache SkyWalking PPMC吴晟在我从事数据库连接池工作过程中给予的指导与帮助。感谢奇点云应用研发总监、首席架构师张聪做为引路人将我领入了数据库连接池的领域，在你的支持与鼓励下才促成了这本书的撰写与出版。
感谢技术圈子中每一位充满创意和活力的朋友——何涛、程超、右军、李艳鹏、杨俊，以及名单之外的更多朋友，感谢你们长期对我的帮助与信任。
感谢机械工业出版社华章公司的编辑杨福川老师和孙海亮老师，在这一年多的时间中始终支持我的写作，你们的鼓励和帮助引导我能顺利完成全部书稿。
感谢加工编辑王玉婵老师为本书付出的劳动。
最后感谢我的爸爸、妈妈、小姨、姨夫、爷爷、奶奶、外公、外婆，感谢你们将我培养成人，并时时刻刻为我灌输着信心和力量！
谨以此书献给我最亲爱的家人，以及众多热爱HikariCP的朋友们！第一篇 准备篇
·第1章 阿里中间件实战，第一个案例
·第2章 数据库连接池江湖
·第3章 初识HikariCP第1章 阿里中间件实战，第一个案例
在应用系统开发过程中，池化技术，如对象池、连接池、线程池等被广泛用来提升性能，原理是通过复用对象而减少创建、释放连接的消耗。由于TCP连接的创建开支是昂贵的，数据库所能承载的TCP并发连接数也是有限制的，针对这种场景，数据库连接池应运而生。数据库连接池的实现有很多，如c3p0、DBCP、Druid等，也包括本书将详细介绍的、号称性能最好的数据库连接池——HikariCP。
关于这个问题该从何说起呢？按照传统做法，一开始介绍某个软件时，首先应该大致介绍它的概念、历史起源、适用场合、发展现状和趋势、大致原理、架构思路、操作环境搭建方法等。可是若有人在技术大会上介绍这些东西，在一个20几页的技术PPT中，有18页讲概念、两页讲实战、最后一页进行答疑FAQ，大都会让我昏昏欲睡、失去听讲的耐心。
所以，我决定在这里从一个有趣的实例说起。在此过程中，我将告诉你很多和连接相关的道理，并且让你对系统的调优过程有一点感觉，然后我才能向你展开通常的原理介绍。这个例子是我在阿里巴巴公司负责多年期间对一款中间件调优的真实经历，这款中间件做过全链路压测、经历过3年双十一大促、接入多种监控、数次重构改造并修复等一系列事件。这款中间件是纯TCP的，再回首，我并不为当年所做的那些TCP性能优化感到自豪，相反地，我却认为一款池化的中间件如果提炼出来则可以更加有利于技术产品的快速落地及运维，进而更好地提升研发效能。
希望读者通过体会这个小例子可以了解到在没有池化技术的情况下TCP调优是如何进行的，我相信通过这个例子，读者朋友能理解TCP调优的复杂性，体会到池化技术出现的必然性。数据库连接池同样是池化技术，大家也可以深入思考并想象一下数据库连接池中间件需要解决哪些问题。1.1 物联网MQTT单机压测130万参数调优
2019年1月，我的一项工作就是为公司搭建一套独立于阿里云之外的自己的物联网MQTT集群。MQTT是非常适合物联网场景的，它可以保持设备与服务器的长连接，避免反复轮询，并支持推送。和数据库连接池一样，它同样运行于TCP协议之上，MQTT相比HTTP具有协议开销低、容忍弱网络、低功耗、百万并发等优点。但是由于当前的阿里云MQTT不支持will、retain msg、QOS2，并且存在限流、断连等不稳定因素，自建MQTT集群这件事就显得格外重要。
在调研了Eclipse Mosquitto后，我又在EMQ（Erlang/Enterprise/[1]Elastic MQTT Broker）的官网上发现了这么一段描述：“EMQ消息服务器1.x版本MQTT连接压力测试到130万，在一台8核心、32G内存的CentOS服务器上。”经过梳理后我认为，它的服务端调优主要分为[2]Linux操作系统参数调优和TCP协议栈网络参数调优两部分。
Linux操作系统参数调优如下：
1）系统全局允许分配的最大文件句柄数。sysctl -w fs.file-max=2097152sysctl -w fs.nr_open=2097152echo 2097152 > /proc/sys/fs/nr_open
2）允许当前会话或进程打开文件句柄数。ulimit -n 1048576
TCP协议栈网络参数调优如下：
1）并发连接backlog设置。sysctl -w net.core.somaxconn=32768sysctl -w net.ipv4.tcp_max_syn_backlog=16384sysctl -w net.core.netdev_max_backlog=16384
2）TCP Socket读写Buffer设置。sysctl -w net.core.rmem_default=262144sysctl -w net.core.wmem_default=262144sysctl -w net.core.rmem_max=16777216sysctl -w net.core.wmem_max=16777216sysctl -w net.core.optmem_max=16777216#sysctl -w net.ipv4.tcp_mem='16777216 16777216 16777216'sysctl -w net.ipv4.tcp_rmem='1024 4096 16777216'sysctl -w net.ipv4.tcp_wmem='1024 4096 16777216'
3）TCP连接追踪设置。sysctl -w net.nf_conntrack_max=1000000sysctl -w net.netfilter.nf_conntrack_max=1000000sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
4）TIME-WAITSocket最大数量、回收与重用设置。net.ipv4.tcp_max_tw_buckets=1048576# 注意: 不建议开启該设置，NAT模式下可能引起连接RST# net.ipv4.tcp_tw_recycle = 1# net.ipv4.tcp_tw_reuse = 1
5）FIN-WAIT-2 Socket超时设置。net.ipv4.tcp_fin_timeout = 15
TCP/IP参考模型可以分为应用层、传输层、网络层、链路层。TCP和UDP在传输层，应用层除了刚才我们介绍的MQTT，还有HTTP、FTP等。因为MQTT运行于TCP协议之上，所以它的调优也离不开TCP的参数调优，数据库连接池的出现也是为了解决应用与数据库之间TCP的性能问题，当前很多应用，比如服务端和算法服务的交互也离不开TCP的传输。所以了解TCP的调优方式可以夯实这个技术领域调优的基础，一通百通。
光阴荏苒，日月如梭，MQTT的这段调优配置不禁让我回想起了4年前在阿里巴巴公司做的将TCP中间件服务的QPS从百级提升到万级的全链路压测与技术改造的那件往事。[1] http://www.emqtt.com，2019年1月25日已经更新到3.0.1版本，EMQ X R3.0完整支持MQTT V3.1/V3.1.1/V5.0版本协议规范，并扩展支持MQTT-SN、WebSocket、CoAP、Stomp或私有TCP/UDP协议。EMQ X 3.0消息服务器支持单节点100万连接与多节点分布式集群。[2] 100万连接测试所需参数包含Linux内核参数、网络协议栈参数、Erlang虚拟机参数，本书由于主要介绍数据库连接池Linux内核参数、网络协议栈参数的共通部分，Erlang虚拟机参数调优及EMQX消息服务器参数调优部分略去。1.2 阿里中间件TCP四次挥手性能调优实战
重用数据库连接最主要的原因是可以减少应用程序与数据库之间创建或销毁TCP连接的开销，数据库连接池的概念应运而生。如果不使用连接池，TCP四次挥手过程中TIME_WAIT的性能调优是相对比较复杂的，请看下面这个小例子。1.2.1 亿级消息网关Rowan架构
Rowan是一个亿级企业消息网关中间件服务，如图1-1所示。它在业务上为B2B、Aliexpress、集团安全、共享事业部、淘宝等大部门提供邮件、短信、旺旺、站内信、钉钉等消息的持续发送能力，支持的业务包括会员注册、评价、仲裁、用户触达EDM、资金中心对账、交易、营销、物流追踪、卖家认证、CRM、风控合规、反欺诈、风险评测、处罚等。图1-1 Rowan介绍
技术上，Rowan由多个服务和中间件构成，具有模版管理、用户触达、消息管理、EDM无线引流、打点追踪等功能，每天产生的消息过千万，仅仅2016年“双十一大促”当天产生的消息，光邮件类就超过6亿。
以邮件模块为例，Rowan技术架构有过两个时期。第1个时期，业务方请求通过HSF（一种阿里内部类似DUBBO的RPC）请求调用Rowan，Rowan再透传调用阿里云邮SMTP服务。当业务洪峰抵达的时候，海外集群会经常出现超时的情况。这是因为，当时阿里云国内集群的系统设计能力比较强，基本上可以支撑国内的邮件发送；相对于国内有5个数据库集群，国外阿里云集群则显得有些薄弱，仅有一个数据库集群。国内集群的系统设计能力是1亿/天，日常2000多万/天；海外日常1000多万/天，峰值1500多万/天。阿里云使用写磁盘的方式，若投递信息失败，重试5次，大致时间点是2分钟、5分钟、30分钟、1小时、2小时，若2小时仍发送失败则丢弃信息。但是，只要是被阿里云SMTP挡住的，如返回给Rowan的connection reset、451、526等异常，不进入阿里云队列，这就会造成只有Rowan这里[1]会打印出异常信息，而阿里云服务端则打印不出具体异常信息，排查问题相当棘手。
由于国内外知名的邮件服务器，如亚马逊AWS、搜狐SENDCLOUD等都是支持抗堆积的，在无法推动阿里云从SMTP支持到HTTP的背景下，我进行了第2个时期的技术改造设计，如图1-2所示。图1-2 改造后Rowan技术架构图
在这个架构中，所有外部服务通过Rowan Service调用对应的服务，如“邮件”等。首先会根据Cache缓存中的模版信息组装成消息体，并存储在HBASE中进行发送状态的记载；其次请求的消息会直接丢到对应的中美MQ（阿里内部叫Metaq，对外开源叫RocketMQ）消息队列集群中，在线流式实时计算Jstorm会分别处理MQ中的邮件、短信、站内信、HTTP、旺旺、钉钉等消息，来进行消息的投递。
由于杭州的阿里云邮系统能力远远高于美国集群，所以美国集群若命中了国内邮箱，比如126、163、QQ等，会直接路由到国内阿里云网关进行发送。在图1-2中，Rowan服务是MQ的生产者，Jstorm是MQ的消费者，故流控和暂停功能放在了消费者这里。流控功能是基于阿里配置中心Diamond定制化开发的，Jstorm启动时直接从配置项读取MQ最大线程、最小线程数。在Diamond中还可以配置海外集群的压力疏导功能，支持按照百分比将流量转移到国内。利用Diamond配置中心实时更新的特性，当Diamond修改时可以实时推送给对应机房以指定的流控线程数重启MQ消费者客户端。
阿里云可以配置发件账号的优先级，并暂停低优先级的账号。Rowan这套新架构在此基础上额外支持两个类似的扩展功能：自带无效地址，可以关掉对指定收件人的发送；模版禁用也可以直接关掉此类模版的发送。
这套架构采用疏导的策略，旨在将海外集群的压力转移到国内分担，从而大幅度提高系统的整体QPS。这套架构需要业务进行配合，通过统计国内外邮件账号的QPS指标、进行国内外发件账号的优先级排序、准备发送故障预案、精简合并系统通知邮件、均匀化编排大促营销邮件发送等一系列措施，来保障整体系统“双十一大促”的稳定性。这也是我在阿里巴巴公司工作期间学会的，技术驱动业务，团队[2]合作，“贴着业务走，以结果为导向”是中间件团队的职责。[1] 当时阿里云提供的是TCP接口，如果也像AWS、SENDCLOUD等那样提供HTTP，那么双方服务端都可以打印出信息。[2] 阿里巴巴公司的“六脉神剑”——阿里人的价值观：客户第一、团队合作、拥抱变化、激情、诚信、敬业。1.2.2 人脸识别服务：异曲同工的架构
提到疏导的架构和QPS的提升，顺便提一个我在2019年工作中设计的大幅度提升QPS的异曲同工的技术方案。
如图1-3所示，FaceServer是基于Java的人脸识别服务，对业务服务提供人脸识别验证的Dubbo接口，同时调用基于Python的算法人脸识别服务。算法服务包括多个原子服务，如人脸、质量、属性、活体、特征等。据统计，FaceServer服务调用算法人脸识别服务，平均每天有40～50次超时异常，最多的时候有100次。技术团队因此对算法服务器单机进行了压测，单机10个线程，平均响应时间在2.878秒左右（FaceServer认为3秒即超时），最长响应时间为13.814秒，QPS为1。图1-3 历史架构
FaceServer在物联网时代，就类似于淘宝网等网站的会员登录，是互联网的门面，QPS为1显然不能满足商业化需求。很多做研发的资深人士可能会想，可以堆机器来提高QPS呀！这其实是不可行的，因为算法服务器非常特别，不同于普通的服务器，它是昂贵的GPU密集型服务器：一台阿里云GPU服务器单机每月要6000元，一年7.2万元，按照图1-3采购两台，一年总计14.4万元。也就是说，目前单机只有1QPS，两台机器2QPS，要支持200QPS，如果堆机器，一年就需要花1400多万元。为了QPS达到200，一年1400多万元的开销，绝对不是中小型创业公司能够承担的，在降成本的大型BAT，诸如阿里巴巴这样的公司，想必也是不能接受的。
目前的算法服务器是单点，另一台算法GPU服务器由于历史原因一直没有启用，所以第1步改造我决定先高效利用好两台已有的算法GPU服务器。在进行了将单机部署提升为集群部署、算法服务内部的串行改并行、耗时原子服务多开进程等工作后，FaceServer的维护者表示再也没有出现过线上的超时异常的情况，此时的架构如图1-4所示。经团队压测后，单机的QPS已经从1提升到了7，由于线上正在使用人脸识别服务，整体集群QPS没有进行压测，估计应该是1+1>2的效果（集群14QPS）。图1-4 第1版优化架构
基于百度人脸识别算法，对于企业认证的用户可以直接免费提供每月15QPS的服务推测，百度应该也是有一些性能优化的技巧来高效利用GPU服务器的，因此目前这样的架构还是可以继续提高QPS的。于是，我又和算法团队进行了进一步的沟通，有收获的是，据算法团队反馈，算法服务器内部单独处理一张人脸图片和批量处理其实是一样的处理。算法团队表示，在单模型情况下，当前人脸特征模型单机进程如果使用批处理至少可以将QPS提高到35，而这恰恰就是可以大幅度提升QPS的切入点。根据算法团队批处理的需求，我于是想到了一个请求合并的架构。
如图1-5所示就是第2版优化架构。这是一种请求合并的处理架构[1]，也是中间件性能提升中较为常见的方案。对于业务服务来说，依然是通过Dubbo同步调用FaceServer服务的，然而FaceServer则是将每次请求丢到一个队列中去，这个队列当请求收集到一定数量（比如算法服务的35QPS）时则进行提交或者每秒进行提交，这种同步转异步的方式可以充分利用算法GPU服务器的资源，从而大幅度提升QPS。在图1-5的架构中，我采用了Guava而没有采用Redis，原因是Redis进行人脸图片的读写会有网络开销，采用Guava会在更大程度上提升响应时间。另外，关于图1-5重试的部分我也使用了GuavaRetry，充分利用了Guava的缓存和重试工具特性。图1-5 第2版优化架构
这种Dubbo同步转异步、请求合并的方案，其实和Rowan的抗堆积、流控与暂停有着异曲同工之妙，都是在有限的资源（人力、物力）的基础上充分合理利用已有资源，从而达到更为极致的QPS。[1] Java与Netty也可以实现这样的高性能高并发，将Nginx和Lua做请求合并也是可以的。从理论上说，由于人脸图片一次要上传12K的图片，如果使用Netty+Thrift确实是比较极致的。1.2.3 “双十一大促”全链路压测发现TCP问题
聊完架构，我们继续回到Rowan和TCP的话题。
Rowan邮件功能使用的是SMTP协议，SMTP在七层协议中属于应用层协议，属TCP/IP协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。Rowan对接阿里云云邮网关，阿里云云邮再对接Hotmail、Gmail、Yahoo等邮件服务商。在我日常运维的过程中，会偶发性地出现“Could not connect to SMTP host”异常提示，尤其是在业务方进行EDM（Email Direct Marketing）邮件大规模营销时会频繁发生。
备战“双十一”过程中，我对Rowan进行了全链路技术改造和压测，在进行线上压测邮件服务过程中发现美国集群（US代表美国，HZ代表杭州）在达到1万QPS压力时，Rowan服务端大量产生60多万次的SMTP连接不上阿里云网关的异常，如图1-6所示。图1-6 全链路压测发现TCP问题
阿里的中间件存在百花齐放、百家争鸣的历史，也可以说是野蛮生长、重复造轮子、适者生存的历史。当时还有一款同样的功能的中间件叫EVE，这是一款从阿里巴巴公司B2B时代就存在的历史悠久的中间件，而Rowan则是一款年轻的中间件。和EVE不同的是，Rowan并不是通过堆机器和增加系统复杂度来换高吞吐量的，只使用了中美各4台共计8台Server服务器，Rowan引入Apache的Jstorm技术，SMTP的邮件发送逻辑放在了Jstorm中，引入Jstorm就是想用最少的机器做极致的事。在Jstorm的日志中，我们又拿到了更加详细的异常信息。 Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp-usa.ocm.aliyun.com, port: 25; nested exception is: java.net.NoRouteToHostException: Cannot assign requested address at com.sun.mail.smtp.AliyunSMTPTransport.openServer(AliyunSMTPTransport.java:1764) at com.sun.mail.smtp.AliyunSMTPTransport.protocolConnect(AliyunSMTPTransport.java:587) Caused by: java.net.NoRouteToHostException: Cannot assign requested address at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
然而登录阿里云的服务器查看系统指标，以及阿里云云邮系统的神农监控、盘古等指标都没有问题。查看Jstorm服务器套接字socket使用概况，可以根据上述异常SMTP 25端口用netstat-tn|grep:25|wc-l命令，或者使用ss–s（Socket Statistics缩写）命令。如图1-7和图1-8所示是连续两次截图记录，可以看出timewait非常多。图1-7 第1次查看结果图1-8 第2次查看结果
种种迹象表明，问题发生在Client端而不是Server端，这是一起典型的TCP调优案例。1.2.4 Linux内核网络参数调优
首先我们调整一下Linux内核参数来提高服务器并发处理能力。一般来说，这种方式可以不用升级服务器硬件就能最大程度地提高服务器性能，是一种节省成本的做法。内核参数修改了以下4个配置：
·ulimit–n。该文件表示系统里打开文件描述符的最大值，查看之后，发现是1024，这个值偏小，我们调大一些。
·somaxconnSocket。cat/proc/sys/net/core/somaxconn，该文件表示等待队列的长度，默认是128，我们调大到1000。
·netdev_max_backlog。cat/proc/sys/net/core/netdev_max_backlog，该文件表示在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目，我们将该值调整到1000。
·tcp_max_syn_backlog。cat/proc/sys/net/ipv4/tcp_max_syn_backlog，该文件表示SYN队列的长度，默认为1024，加大队列长度为8192，以容纳更多等待连接的网络连接。
修改完毕以后，重新进行线上压测，然而问题没有解决，QPS也没有得到提升。小窍门 本节主要是对/proc/sys/net/进行优化，该目录下的配置文件主要用来控制内核和网络层之间的交互行为，一些技巧补充如下：
1）/proc/sys/net/core/message_burst该文件表示写新的警告消息所需的时间（以1/10秒为单位），在这个时间内系统接收到的其他警告消息会被丢弃。这用于防止某些企图用消息“淹没”系统的人所使用的拒绝服务（Denial of Service）攻击。缺省：50（5秒）。
2）/proc/sys/net/core/message_cost该文件表示写每个警告消息相关的成本值。该值越大，越有可能忽略警告消息。缺省：5。
3）/proc/sys/net/core/netdev_max_backlog该文件表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。缺省：300。
4）/proc/sys/net/core/optmem_max该文件表示每个套接字所允许的最大缓冲区的大小。缺省：10240。
5）/proc/sys/net/core/rmem_default该文件指定了接收套接字缓冲区大小的缺省值（以字节为单位）。缺省：110592。
6）/proc/sys/net/core/rmem_max该文件指定了接收套接字缓冲区大小的最大值（以字节为单位）。缺省：131071。
7）/proc/sys/net/core/wmem_default该文件指定了发送套接字缓冲区大小的缺省值（以字节为单位）。缺省：110592。
8）/proc/sys/net/core/wmem_max该文件指定了发送套接字缓冲区大小的最大值（以字节为单位）。缺省：131071。1.2.5 Linux TCP参数调优
TIME_WAIT是TCP中一个很重要的状态，在大并发的短连接下，会产生很多TIME_WAIT，这会消耗很多系统资源；端口的数量只有65535，占用一个就会少一个，进而严重影响新连接。所以需要调优TCP参数，从而让系统更快地释放TIME_WAIT的连接。TCP的传输连接有连接建立、数据传送和连接释放3个阶段，多年前在与阿里巴巴公司叶军博士一次闲聊中得知，作为阿里巴巴公司面试官他经常会考察应聘者TCP的3次握手和4次挥手这个知识点。
对于TIME_WAIT，我们主要进行如下的修改：net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_tw_reuse = 1
这两个参数默认是关闭的，但是不建议开启该设置，NAT模式下可能引起连接RST。这两个参数的作用是主动断连接，它由于违反了[1][2]TCP协议（RFC 1122），在其官方文档中也强调“It should not be changed without advice/request of technical”。
下面4个是TCP主要内核参数的说明：
·net.ipv4.tcp_syncookies=1表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击。默认为0，表示关闭。
·net.ipv4.tcp_tw_reuse=1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接。默认为0，表示关闭。
·net.ipv4.tcp_tw_recycle=1表示开启TCP连接中TIME-WAIT sockets的快速回收。默认为0，表示关闭。
·net.ipv4.tcp_fin_timeout修改系统默认的TIMEOUT时间。
我们可以再继续进行并发连接backlog调优，并对可用端口调优范围、TCP Socket读写Buffer、TIME-WAIT Socket最大数量、FIN-WAIT-2 Socket超时设置等进行优化。特别说明一下，tcp_max_tw_buckets用于控制并发时，TIME_WAIT的数量默认值是180000，如果超过，系统会清除多余的，并警告“time wait bucket table overflow”。这些参数的调优不但能够提升服务器的负载，还可以在一定程度上防御DDoS等攻击。
在参数调优之后，又上了一道双保险，重新修改了com.sun.mail.smtp源码的SO_REUSEADDR，通过serverSocket.setReuseAddress(true)让其在服务器绑定端口前生效，目的是让端口释放后立即就可以被再次使用。
但是发布到线上进行压测以后，却依然没有效果。[1] http://tools.ietf.org/html/rfc1122[2] https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
试读结束[说明：试读内容隐藏了图片]