高并发与高可用知识总结

悠悠 2021-09-20 15:48 514阅读 0赞

## **微信搜索：“二十同学” 公众号，欢迎关注一条不一样的成长之路** ##

## 究竟啥才是互联网架构“高并发” ##

**一、什么是高并发**

**高并发（**High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

**响应时间**：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

**吞吐量**：单位时间内处理的请求数量。

**QPS**：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

**并发用户数**：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

**二、如何提升系统的并发能力**

互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

**垂直扩展**：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。

不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。

**水平扩展**：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。

**三、常见的互联网分层架构**

![format_png][]  
常见互联网分布式架构如上，分为：

（1）**客户端层**：典型调用方是浏览器browser或者手机应用APP

（2）**反向代理层**：系统入口，反向代理

（3）**站点应用层**：实现核心应用逻辑，返回html或者json

（4）**服务层**：如果实现了服务化，就有这一层

（5）**数据****-****缓存层**：缓存加速访问存储

（6）**数据****-****数据库层**：数据库固化数据存储

整个系统各层次的水平扩展，又分别是如何实施的呢？

**四、分层水平扩展架构实践**

**反向代理层的水平扩展**

![format_png 1][]  
反向代理层的水平扩展，是通过“DNS轮询”实现的：dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。

当nginx成为瓶颈的时候，只要增加服务器数量，新增nginx服务的部署，增加一个外网ip，就能扩展反向代理层的性能，做到理论上的无限高并发。

**站点层的水平扩展**

![format_png 2][]  
站点层的水平扩展，是通过“nginx”实现的。通过修改nginx.conf，可以设置多个web后端。

当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。

**服务层的水平扩展**

![format_png 3][]  
服务层的水平扩展，是通过“服务连接池”实现的。

站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。

**数据层的水平扩展**

在数据量很大的情况下，数据层（缓存，数据库）涉及数据的水平扩展，将原本存储在一台服务器上的数据（缓存，数据库）水平拆分到不同服务器上去，以达到扩充系统性能的目的。

互联网数据层常见的水平拆分方式有这么几种，以数据库为例：

**按照范围水平拆分**

![format_png 4][]  
每一个数据服务，存储一定范围的数据，上图为例：

user0库，存储uid范围1-1kw

user1库，存储uid范围1kw-2kw

这个方案的好处是：

（1）规则简单，service只需判断一下uid范围就能路由到对应的存储服务；

（2）数据均衡性较好；

（3）比较容易扩展，可以随时加一个uid\[2kw,3kw\]的数据服务；

不足是：

（1）      请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大；

**按照哈希水平拆分**

![format_png 5][]  
每一个数据库，存储某个key值hash后的部分数据，上图为例：

user0库，存储偶数uid数据

user1库，存储奇数uid数据

这个方案的好处是：

（1）规则简单，service只需对uid进行hash能路由到对应的存储服务；

（2）数据均衡性较好；

（3）请求均匀性较好；

不足是：

（1）不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移；

这里需要注意的是，通过水平拆分来扩充系统性能，与主从同步读写分离来扩充数据库性能的方式有本质的不同。

通过水平拆分扩展数据库性能：

（1）每个服务器上存储的数据量是总量的1/n，所以单机的性能也会有提升；

（2）n个服务器上的数据没有交集，那个服务器上数据的并集是数据的全集；

（3）数据水平拆分到了n个服务器上，理论上读性能扩充了n倍，写性能也扩充了n倍（其实远不止n倍，因为单机的数据量变为了原来的1/n）；

通过主从同步读写分离扩展数据库性能：

（1）每个服务器上存储的数据量是和总量相同；

（2）n个服务器上的数据都一样，都是全集；

（3）理论上读性能扩充了n倍，写仍然是单点，写性能不变；

缓存层的水平拆分和数据库层的水平拆分类似，也是以范围拆分和哈希拆分的方式居多，就不再展开。

**五、总结**

**高并发（**High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。

互联网分层架构中，各层次水平扩展的实践又有所不同：

（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；

（2）站点层可以通过nginx来进行水平扩展；

（3）服务层可以通过服务连接池来进行水平扩展；

（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；

各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。

## 高并发的常见应对方案 ##

**一、关于并发****我们说的高并发是什么？**

在互联网时代，高并发，通常是指，在某个时间点，有很多个访问同时到来。

**高并发，通常关心的系统指标与业务指标？**

*  **QPS**：每秒钟查询量，广义的，通常指指每秒请求数
 *  **响应时间**：从请求发出到收到响应花费的时间，例如：系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间
 *  **带宽**：计算带宽大小需关注两个指标，峰值流量和页面的平均大小 
 *  **PV**：综合浏览量(Page View)，即页面浏览量或者点击量，通常关注在24小时内访问的页面数量，即“日PV”
 *  **UV**：独立访问(UniQue Visitor)，即去重后的访问用户数，通常关注在24小时内访问的用户，即“日UV”

**二、关于三种应对大并发的常见优化方案**

**【数据库缓存】**

**为什么是要使用缓存？**

缓存数据是为了让客户端很少甚至不访问数据库，减少磁盘IO，提高并发量，提高应用数据的响应速度。

**【CDN加速】**

**什么是CDN？**

CDN的全称是Content Delivery Network，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离等综合信息将用户的请求重新导向离用户最近的服务节点上。

**使用CDN的优势？**

CDN的本质是内存缓存，就近访问，它提高了企业站点(尤其含有大量图片和静态页面站点)的访问速度，跨运营商的网络加速，保证不同网络的用户都得到良好的访问质量。

同时，减少远程访问的带宽，分担网络流量，减轻原站点WEB服务器负载。

**【服务器的集群化，以及负载均衡】**

**什么是七层负载均衡？**

七层负载均衡，是基于http协议等应用信息的负载均衡，最常用的就是Nginx，它能够自动剔除工作不正常的后端服务器，上传文件使用异步模式，支持多种分配策略，可以分配权重，分配方式灵活。

内置策略：IP Hash、加权轮询

扩展策略：fair策略、通用hash、一致性hash

**什么是加权轮询策略？**

首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器，即体现了加权权重，又体现了轮询。

## 究竟啥才是互联网架构“高可用” ##

**一、什么是高可用**

**高可用HA****（**High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务，我们说系统的可用性是100%。

如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。

很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。

百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。

**二、如何保障系统的高可用**

我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。

**保证系统高可用，架构设计的核心准则是：冗余。**

有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中，如何通过**冗余+自动故障转移**来保证系统的高可用特性。

**三、常见的互联网分层架构**

![format_png 6][]  
常见互联网分布式架构如上，分为：

（1）**客户端层**：典型调用方是浏览器browser或者手机应用APP

（2）**反向代理层**：系统入口，反向代理

（3）**站点应用层**：实现核心应用逻辑，返回html或者json

（4）**服务层**：如果实现了服务化，就有这一层

（5）**数据****-****缓存层**：缓存加速访问存储

（6）**数据****-****数据库层**：数据库固化数据存储

整个系统的高可用，又是通过每一层的**冗余****+****自动故障转移**来综合实现的。

**四、分层高可用架构实践**

**【客户端层->****反向代理层】的高可用**

![format_png 7][]  
【客户端层】到【反向代理层】的**高可用**，是通过反向代理层的冗余来实现的。以nginx为例：有两台nginx，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。

![format_png 8][]  
**自动故障转移**：当nginx挂了的时候，keepalived能够探测到，会自动的进行故障转移，将流量自动迁移到shadow-nginx，由于使用的是相同的virtual IP，这个切换过程对调用方是透明的。

**【反向代理层->****站点层】的高可用**

![format_png 9][]  
【反向代理层】到【站点层】的**高可用**，是通过站点层的冗余来实现的。假设反向代理层是nginx，nginx.conf里能够配置多个web后端，并且nginx能够探测到多个后端的存活性。

![format_png 10][]  
**自动故障转移**：当web-server挂了的时候，nginx能够探测到，会自动的进行故障转移，将流量自动迁移到其他的web-server，整个过程由nginx自动完成，对调用方是透明的。

**【站点层->****服务层】的高可用**

![format_png 11][]  
【站点层】到【服务层】的**高可用**，是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。

![format_png 12][]  
**自动故障转移**：当service挂了的时候，service-connection-pool能够探测到，会自动的进行故障转移，将流量自动迁移到其他的service，整个过程由连接池自动完成，对调用方是透明的（所以说RPC-client中的服务连接池是很重要的基础组件）。

**【服务层>****缓存层】的高可用**

![format_png 13][]  
【服务层】到【缓存层】的高可用，是通过缓存数据的冗余来实现的。

缓存层的数据冗余又有几种方式：第一种是利用客户端的封装，service对cache进行双读或者双写。

![format_png 14][]  
缓存层也可以通过支持主从同步的缓存集群来解决缓存层的**高可用**问题。

以redis为例，redis天然支持主从同步，redis官方也有sentinel哨兵机制，来做redis的存活性检测。

![format_png 15][]  
**自动故障转移**：当redis主挂了的时候，sentinel能够探测到，会通知调用方访问新的redis，整个过程由sentinel和redis集群配合完成，对调用方是透明的。

说完缓存的高可用，这里要多说一句，业务对缓存并不一定有“高可用”要求，更多的对缓存的使用场景，是用来“加速数据访问”：把一部分数据放到缓存里，如果缓存挂了或者缓存没有命中，是可以去后端的数据库中再取数据的。

这类允许“cache miss”的业务场景，缓存架构的建议是：

![format_png 16][]  
将kv缓存封装成服务集群，上游设置一个代理（代理可以用集群冗余的方式保证高可用），代理的后端根据缓存访问的key水平切分成若干个实例，每个实例的访问并不做高可用。

![format_png 17][]  
**缓存实例挂了屏蔽**：当有水平切分的实例挂掉时，代理层直接返回cache miss，此时缓存挂掉对调用方也是透明的。key水平切分实例减少，不建议做re-hash，这样容易引发缓存数据的不一致。

**【服务层>****数据库层】的高可用**

大部分互联网技术，数据库层都用了“主从同步，读写分离”架构，所以数据库层的高可用，又分为“读库高可用”与“写库高可用”两类。

**【服务层>****数据库层“读”】的高可用**

![format_png 18][]  
【服务层】到【数据库读】的**高可用**，是通过读库的冗余来实现的。

既然冗余了读库，一般来说就至少有2个从库，“数据库连接池”会建立与读库多个连接，每次请求会路由到这些读库。

![format_png 19][]  
**自动故障转移**：当读库挂了的时候，db-connection-pool能够探测到，会自动的进行故障转移，将流量自动迁移到其他的读库，整个过程由连接池自动完成，对调用方是透明的（所以说DAO中的数据库连接池是很重要的基础组件）。

**【服务层>****数据库层“写”】的高可用**

![format_png 20][]  
【服务层】到【数据库写】的**高可用**，是通过写库的冗余来实现的。

以mysql为例，可以设置两个mysql双主同步，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。

![format_png 21][]  
**自动故障转移**：当写库挂了的时候，keepalived能够探测到，会自动的进行故障转移，将流量自动迁移到shadow-db-master，由于使用的是相同的virtual IP，这个切换过程对调用方是透明的。

**五、总结**

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

方法论上，高可用是通过**冗余****+****自动故障转移**来实现的。

整个互联网分层系统架构的高可用，又是通过每一层的**冗余****+****自动故障转移**来综合实现的，具体的：

（1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移

（2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移

（3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移

（4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性

（5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移

（6）【服务层】到【数据库“写”】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移

## 互联网架构，如何进行容量设计？ ##

## **一，需求缘起** ##

互联网公司，这样的场景是否似曾相识：

场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题：

（1）机器能抗住么？

（2）如果扛不住，需要加多少台机器？

场景二：系统设计阶段，技术老大杀过来，又问了两个问题：

（1）数据库需要分库么？

（2）如果需要分库，需要分几个库？

技术上来说，这些都是系统容量预估的问题，**容量设计是架构师必备的技能之一**。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，今天分享的内容，就以【并发量】为例，看看如何回答好这两个问题。

## **二，容量评估的步骤与方法** ##

**【步骤一：评估总访问量】**

如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？

答案是：询问业务方，询问运营同学，询问产品同学，看对运营活动或者产品上线后的预期是什么。

举例：58要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，求push落地页系统的总访问量？

回答：5000w\*10% = 500w

**【步骤二：评估平均访问量QPS】**

如何知道平均访问量QPS？

答案是：有了总量，除以总时间即可，如果按照天评估，一天按照4w秒计算。

举例1：push落地页系统30分钟的总访问量是500w，求平均访问量QPS

回答：500w/(30\*60) = 2778，大概3000QPS

举例2：主站首页估计日均pv 8000w，求平均访问QPS

回答：一天按照4w秒算，8000w/4w=2000，大概2000QPS

提问：为什么一天按照4w秒计算？

回答：一天共24小时\*60分钟\*60秒=8w秒，一般假设所有请求都发生在白天，所以一般来说一天只按照4w秒评估

**【步骤三：评估高峰QPS】**

系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？

答案是：根据业务特性，通过业务访问曲线评估

举例：日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？

![format_png 22][]  
回答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。

说明：有一些业务例如“秒杀业务”比较难画出业务访问趋势图，这类业务的容量评估不在此列。

**【步骤四：评估系统、单机极限QPS】**

如何评估一个业务，一个服务单机能的极限QPS呢？

答案是：压力测试

在一个服务上线前，一般来说是需要进行压力测试的（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：

![format_png 23][]  
1）访问端是APP

2）运营活动H5落地页是一个web站点

3）H5落地页由缓存cache、数据库db中的数据拼装而成

通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。一般来说，线上系统是不会跑满到极限的，打个8折，单机线上允许跑到QPS1000。

**【步骤五：根据线上冗余度回答两个问题】**

好了，上述步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，就能自信自如的回答技术老大提出的问题了：

（1）机器能抗住么？ -> 峰值5000，单机1000，线上2台，扛不住

（2）如果扛不住，需要加多少台机器？ -> 需要额外3台，提前预留1台更好，给4台更稳

除了并发量的容量预估，数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤。

## **三，总结** ##

互联网架构设计如何进行容量评估：

**【步骤一：评估总访问量】** -> 询问业务、产品、运营

**【步骤二：评估平均访问量QPS】**\-> 除以时间，一天算4w秒

**【步骤三：评估高峰QPS】** -> 根据业务曲线图来

**【步骤四：评估系统、单机极限QPS】** -> 压测很重要

**【步骤五：根据线上冗余度回答两个问题】** -> 估计冗余度与线上冗余度差值

## 如何实现超高并发的无锁缓存？ ##

## **一、需求缘起** ##

**【业务场景】**

有一类写多读少的业务场景：大部分请求是对数据进行修改，少部分请求对数据进行读取。

例子1：滴滴打车，某**个司机地理位置信息的变化**（可能每几秒钟有一个修改），以及司机地理位置的读取（用户打车的时候查看某个司机的地理位置）。

void **SetDriverInfo**(long driver\_id, DriverInfoi); // 大量请求调用修改司机信息，可能主要是GPS位置的修改

DriverInfo **GetDriverInfo**(long driver\_id);  // 少量请求查询司机信息

例子2：**统计计数的变化**，某个url的访问次数，用户某个行为的反作弊计数（计数值在不停的变）以及读取（只有少数时刻会读取这类数据）。

void **AddCountByType**(long type); // 大量增加某个类型的计数，修改比较频繁

long **GetCountByType**(long type); // 少量返回某个类型的计数

**【底层实现】**

具体到底层的实现，往往是一个Map（本质是一个**定长key，定长value**的缓存结构）来存储司机的信息，或者某个类型的计数。

Map<driver\_id, DriverInfo>

Map<type, count>

**【临界资源】**

这个Map存储了所有信息，当并发读写访问时，它作为临界资源，在读写之前，一般要进行加锁操作，以司机信息存储为例：

void SetDriverInfo(long driver\_id, DriverInfoinfo)\{

**WriteLock (m\_lock);**

Map<driver\_id>= info;

**UnWriteLock(m\_lock);**

DriverInfo GetDriverInfo(long driver\_id)\{

DriverInfo t;

**ReadLock(m\_lock);**

t= Map<driver\_id>;

**UnReadLock(m\_lock);**

return t;

**【并发锁瓶颈】**

假设滴滴有100w司机同时在线，每个司机没5秒更新一次经纬度状态，那么每秒就有20w次写并发操作。假设滴滴日订单1000w个，平均每秒大概也有300个下单，对应到查询并发量，可能是1000级别的并发读操作。

上述实现方案没有任何问题，但**在并发量很大的时候（每秒20w写，1k读），锁m\_lock会成为潜在瓶颈，**在这类高并发环境下写多读少的业务仓井，如何来进行优化，是本文将要讨论的问题。

## **二、水平切分+锁粒度优化** ##

上文中之所以锁冲突严重，是因为所有司机都公用一把锁，锁的粒度太粗（可以认为是一个数据库的“库级别锁”），是否可能进行水平拆分（类似于数据库里的分库），把一个库锁变成多个库锁，来提高并发，降低锁冲突呢？显然是可以的，把1个Map水平切分成多个Map即可：

void SetDriverInfo(long driver\_id, DriverInfoinfo)\{

i= driver\_id % N; // 水平拆分成N份，N个Map，N个锁

**WriteLock (m\_lock \[i\]);  //****锁第i****把锁**

Map\[i\]<driver\_id>= info;  // 操作第i个Map

**UnWriteLock (m\_lock\[i\]); // ****解锁第i****把锁**

每个Map的并发量（变成了1/N）和数据量都降低（变成了1/N）了，所以理论上，锁冲突会成平方指数降低。

分库之后，仍然是库锁，有没有办法变成数据库层面所谓的“行级锁”呢，难道要把x条记录变成x个Map吗，这显然是不现实的。

## **三、MAP变Array+最细锁粒度优化** ##

假设driver\_id是递增生成的，并且缓存的内存比较大，是可以把Map优化成Array，而不是拆分成N个Map，是有可能把锁的粒度细化到最细的（每个记录一个锁）。

void SetDriverInfo(long driver\_id, DriverInfoinfo)\{

index= driver\_id;

**WriteLock (m\_lock \[index\]);  //****超级大内存，一条记录一个锁，锁行锁**

Array\[index\]= info; //driver\_id就是Array下标

**UnWriteLock (m\_lock\[index\]); // ****解锁行锁**

![format_png 24][]  
和上一个方案相比，这个方案使得锁冲突降到了最低，但锁资源大增，在数据量非常大的情况下，一般不这么搞。数据量比较小的时候，可以一个元素一个锁的（典型的是连接池，每个连接有一个锁表示连接是否可用）。

上文中提到的另一个例子，用户操作类型计数，操作类型是有限的，即使一个type一个锁，锁的冲突也可能是很高的，还没有方法进一步提高并发呢？

## **四、把锁去掉，变成无锁缓存** ##

**【无锁的结果】**

void AddCountByType(long type /\*, int count\*/)\{

//不加锁

Array\[type\]++; // 计数++

//Array\[type\] += count; // 计数增加count

![format_png 25][]  
如果这个缓存不加锁，当然可以达到最高的并发，但是多线程对缓存中同一块定长数据进行操作时，有可能出现不一致的数据块，这个方案为了提高性能，牺牲了一致性。在读取计数时，获取到了错误的数据，是不能接受的（作为缓存，允许cache miss，却不允许读脏数据）。

**【脏数据是如何产生的】**

这个并发写的脏数据是如何产生的呢，详见下图：

![format_png 26][]  
1）线程1对缓存进行操作，对key想要写入value1

2）线程2对缓存进行操作，对key想要写入value2

3）如果不加锁，线程1和线程2对同一个定长区域进行一个并发的写操作，**可能每个线程写成功一半，导致出现脏数据产生**，最终的结果即不是value1也不是value2，而是一个乱七八糟的不符合预期的值value-unexpected。

**【数据完整性问题】**

并发写入的数据分别是value1和value2，读出的数据是value-unexpected，数据的篡改，这本质上是一个数据完整性的问题。**通常如何保证数据的完整性呢？**

**例子1**：运维如何保证，从中控机分发到上线机上的二进制没有被篡改？

**回答**：md5

**例子2**：即时通讯系统中，如何保证接受方收到的消息，就是发送方发送的消息？

**回答**：发送方除了发送消息本身，还要发送消息的签名，接收方收到消息后要校验签名，以确保消息是完整的，未被篡改。

当当当当 => “签名”是一种常见的保证数据完整性的常见方案。

**【加上签名之后的流程】**

![format_png 27][]

加上签名之后，不但缓存要写入定长value本身，还要写入定长签名（例如16bitCRC校验）：

1）线程1对缓存进行操作，对key想要写入value1，写入签名v1-sign

2）线程2对缓存进行操作，对key想要写入value2，写入签名v2-sign

3）如果不加锁，线程1和线程2对同一个定长区域进行一个并发的写操作，可能每个线程写成功一半，导致出现脏数据产生，最终的结果即不是value1也不是value2，而是一个乱七八糟的不符合预期的值value-unexpected，但签名，一定是v1-sign或者v2-sign中的任意一个

4）数据读取的时候，不但要取出value，还要像消息接收方收到消息一样，校验一下签名，**如果发现签名不一致，缓存则返回NULL，即cache miss**。

当然，对应到司机地理位置，与URL访问计数的case，除了内存缓存之前，肯定需要timer对缓存中的数据定期落盘，写入数据库，如果cache miss，可以从数据库中读取数据。

## **五、总结** ##

在【超高并发】，【写多读少】，【定长value】的【业务缓存】场景下：

1）可以通过**水平拆分**来降低锁冲突

2）可以通过**Map转Array**的方式来最小化锁冲突，一条记录一个锁

3）可以**把锁去掉**，最大化并发，但带来的数据完整性的破坏

4）可以通过签名的方式保证数据的完整性，实现**无锁缓存**

## 多库多事务降低数据不一致概率 ##

## **一、案例缘起** ##

我们经常使用事务来保证数据库层面数据的ACID特性。

举个栗子，用户下了一个订单，需要修改余额表，订单表，流水表，于是会有类似的伪代码：

start transaction;

CURDtable t\_account;  any Exception rollback;

CURDtable t\_order;       any Exceptionrollback;

CURDtable t\_flow;         any Exceptionrollback;

commit;

如果对余额表，订单表，流水表的SQL操作全部成功，则全部提交，如果任何一个出现问题，则全部回滚，以保证数据的一致性。

互联网的业务特点，数据量较大，并发量较大，经常使用拆库的方式提升系统的性能。**如果进行了拆库，余额、订单、流水可能分布在不同的数据库上，甚至不同的数据库实例上，此时就不能用事务来保证数据的一致性了。**这种情况下如何保证数据的一致性，是今天要讨论的话题。

## **二、补偿事务** ##

补偿事务是一种在业务端实施业务逆向操作事务，来保证业务数据一致性的方式。

举个栗子，修改余额表事务为

int Do\_AccountT(uid, money)\{

start transaction;

//余额改变money这么多

CURDtable t\_account with money;       anyException rollback return NO;

commit;

return YES;

那么补偿事务可以是：

int Compensate\_AccountT(uid, money)\{

//做一个money的反向操作

returnDo\_AccountT(uid, -1\*money)\{

同理，订单表操作为

Do\_OrderT，新增一个订单

Compensate\_OrderT，删除一个订单

要保重余额与订单的一致性，可能要写这样的代码：

// 执行第一个事务

int flag = Do\_AccountT();

if(flag=YES)\{

//第一个事务成功，则执行第二个事务

flag= Do\_OrderT();

if(flag=YES)\{

// 第二个事务成功，则成功

returnYES;

else\{

// 第二个事务失败，执行第一个事务的补偿事务

Compensate\_AccountT();

该方案的**不足**是：

（1）不同的业务要写不同的补偿事务，不具备通用性

（2）没有考虑补偿事务的失败

（3）如果业务流程很复杂，if/else会嵌套非常多层

例如，如果上面的例子加上流水表的修改，加上Do\_FlowT和Compensate\_FlowT，可能会变成一个这样的if/else：

// 执行第一个事务

int flag = Do\_AccountT();

if(flag=YES)\{

//第一个事务成功，则执行第二个事务

flag= Do\_OrderT();

if(flag=YES)\{

// 第二个事务成功，则执行第三个事务

flag= Do\_FlowT();

if(flag=YES)\{

//第三个事务成功，则成功

returnYES;

else\{

// 第三个事务失败，则执行第二、第一个事务的补偿事务

flag =Compensate\_OrderT();

if … else … // 补偿事务执行失败？

flag= Compensate\_AccountT();

if … else … // 补偿事务执行失败？

else\{

// 第二个事务失败，执行第一个事务的补偿事务

Compensate\_AccountT();

if … else … // 补偿事务执行失败？

## **三、事务拆分分析与后置提交优化** ##

单库是用这样一个大事务保证一致性：

start transaction;

CURDtable t\_account;  any Exception rollback;

CURDtable t\_order;       any Exceptionrollback;

CURDtable t\_flow;         any Exceptionrollback;

commit;

拆分成了多个库，大事务会变成三个小事务：

start transaction1;

//第一个库事务执行

CURDtable t\_account;  any Exception rollback;

…

// 第一个库事务提交

commit1;

start transaction2;

//第二个库事务执行

CURDtable t\_order;       any Exceptionrollback;

…

// 第二个库事务提交

commit2;

start transaction3;

//第三个库事务执行

CURDtable t\_flow;         any Exceptionrollback;

…

// 第三个库事务提交

commit3;

**一个事务，分成执行与提交两个阶段，执行的时间其实是很长的，而commit的执行其实是很快的**，于是整个执行过程的时间轴如下：

![format_png 28][]  
第一个事务执行200ms，提交1ms；

第二个事务执行120ms，提交1ms；

第三个事务执行80ms，提交1ms；

**那在什么时候系统出现问题，会出现不一致呢？**

**回答**：第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题（例如服务器重启，数据库异常等），都可能导致数据不一致。

![format_png 29][]

如果改变事务执行与提交的时序，变成事务先执行，最后一起提交，情况会变成什么样呢：

![format_png 30][]  
第一个事务执行200ms；

第二个事务执行120ms；

第三个事务执行80ms；

第一个事务执行1ms；

第二个事务执行1ms；

第三个事务执行1ms；

**那在什么时候系统出现问题，会出现不一致呢？**

问题的答案与之前相同：第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题（例如服务器重启，数据库异常等），都可能导致数据不一致。

![format_png 31][]

**这个变化的意义是什么呢？**

方案一总执行时间是303ms，最后202ms内出现异常都可能导致不一致；

方案二总执行时间也是303ms，但最后2ms内出现异常才会导致不一致；

虽然没有彻底解决数据的一致性问题，但不一致出现的概率大大降低了！

事务提交后置降低了数据不一致的出现概率，**会带来什么副作用呢？**

回答：事务提交时会释放数据库的连接，第一种方案，第一个库事务提交，数据库连接就释放了，后置事务提交的方案，所有库的连接，要等到所有事务执行完才释放。这就意味着，**数据库连接占用的时间增长了，系统整体的吞吐量降低了。**

## **四、总结** ##

trx1.exec();

trx1.commit();

trx2.exec();

trx2.commit();

trx3.exec();

trx3.commit();

优化为：

trx1.exec();

trx2.exec();

trx3.exec();

trx1.commit();

trx2.commit();

trx3.commit();

这个小小的改动（改动成本极低），不能彻底解决多库分布式事务数据一致性问题，但能大大降低数据不一致的概率，带来的副作用是数据库连接占用时间会增长，吞吐量会降低。对于一致性与吞吐量的折衷，还需要业务架构师谨慎权衡折衷。

## 线程数究竟设多少合理 ##

**一、需求缘起**

Web-Server通常有个配置，**最大工作线程数**，后端服务一般也有个配置，工作线程池的**线程数量**，这个线程数的配置不同的业务架构师有不同的经验值，有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些业务设置为CPU核数的32倍。

“工作线程数”的设置依据是什么，到底设置为多少能够最大化CPU性能，是本文要讨论的问题。

## **二、一些共性认知** ##

在进行进一步深入讨论之前，先以提问的方式就一些共性认知达成一致。

**提问：工作线程数是不是设置的越大越好？**

回答：肯定不是的

1）一来服务器CPU核数有限，同时并发的线程数是有限的，1核CPU设置10000个工作线程没有意义

2）线程切换是有开销的，如果线程切换过于频繁，反而会使性能降低

**提问：调用sleep()****函数的时候，线程是否一直占用CPU****？**

回答：不占用，等待时会把CPU让出来，给其他需要CPU资源的线程使用

不止调用sleep()函数，在进行一些阻塞调用，例如网络编程中的**阻塞**accept()【等待客户端连接】和**阻塞**recv()【等待下游回包】也不占用CPU资源

**提问：如果CPU****是单核，设置多线程有意义么，能提高并发性能么？**

回答：即使是单核，使用多线程也是有意义的

1）多线程编码可以让我们的服务/代码更加清晰，有些IO线程收发包，有些Worker线程进行任务处理，有些Timeout线程进行超时检测

2）如果有一个任务一直占用CPU资源在进行计算，那么此时增加线程并不能增加并发，例如这样的一个代码

while(1)\{ i++; \}

该代码一直不停的占用CPU资源进行计算，会使CPU占用率达到100%

3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作

## **三、常见服务线程模型** ##

了解常见的服务线程模型，有助于理解服务并发的原理，一般来说互联网常见的服务线程模型有如下两种

**IO****线程与工作线程通过队列解耦类模型**

![format_png 32][]  
如上图，大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型：

1）**有少数几个IO线程**监听上游发过来的请求，并进行收发包（生产者）

2）**有一个或者多个任务队列**，作为IO线程与Worker线程异步解耦的数据传输通道（临界资源）

3）**有多个工作线程**执行正真的任务（消费者）

这个线程模型应用很广，符合大部分场景，这个线程模型的特点是，**工作线程内部是同步阻塞执行任务的**（回想一下tomcat线程中是怎么执行Java程序的，dubbo工作线程中是怎么执行任务的），因此可以通过增加Worker线程数来增加并发能力，今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。

**纯异步线程模型**

任何地方都没有阻塞，这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量，Lighttpd有一种单进程单线程模式，并发处理能力很强，就是使用的的这种模型。该模型的缺点是：

1）如果使用单线程模式，难以利用多CPU多核的优势

2）程序员更习惯写同步代码，callback的方式对代码的可读性有冲击，对程序员的要求也更高

3）框架更复杂，往往需要server端收发组件，server端队列，client端收发组件，client端队列，上下文管理组件，有限状态机组件，超时管理组件的支持

however，这个模型不是今天讨论的重点。

## **四、工作线程的工作模式** ##

了解工作线程的工作模式，对量化分析线程数的设置非常有帮助：

![format_png 33][]  
上图是一个典型的工作线程的处理过程，从开始处理start到结束处理end，该任务的处理共有7个步骤：

1）从工作队列里拿出任务，进行一些**本地**初始化计算，例如http协议分析、参数解析、参数校验等

2）**访问cache**拿一些数据

3）拿到cache里的数据后，再进行一些**本地**计算，这些计算和业务逻辑相关

4）通过**RPC调用下游service**再拿一些数据，或者让下游service去处理一些相关的任务

5）RPC调用结束后，再进行一些**本地**计算，怎么计算和业务逻辑相关

6）**访问DB**进行一些数据操作

7）操作完数据库之后做一些收尾工作，同样这些收尾工作也是**本地**计算，和业务逻辑相关

分析整个处理的时间轴，会发现：

1）其中1，3，5，7步骤中【上图中粉色时间轴】，线程进行本地业务逻辑计算时**需要占用****CPU**

2）而2，4，6步骤中【上图中橙色时间轴】，访问cache、service、DB过程中线程处于一个等待结果的状态，**不需要占用****CPU**，进一步的分解，这个“等待结果”的时间共分为三部分：

2.1）请求在网络上传输到下游的cache、service、DB

2.2）下游cache、service、DB进行任务处理

2.3）cache、service、DB将报文在网络上传回工作线程

## **五、量化分析并合理设置工作线程数** ##

最后一起来回答工作线程数设置为多少合理的问题。

通过上面的分析，Worker线程在执行的过程中，有一部计算时间需要占用CPU，另一部分等待时间不需要占用CPU，通过量化分析，例如打日志进行统计，可以统计出整个Worker线程执行过程中这两部分时间的比例，例如：

1）时间轴1，3，5，7【上图中粉色时间轴】的计算执行时间是100ms

2）时间轴2，4，6【上图中橙色时间轴】的等待时间也是100ms

得到的结果是，这个线程计算和等待的时间是1：1，即有50%的时间在计算（占用CPU），50%的时间在等待（不占用CPU）：

1）假设此时是**单核**，则设置为2个工作线程就可以把CPU充分利用起来，让CPU跑到100%

2）假设此时是**N核**，则设置为2N个工作现场就可以把CPU充分利用起来，让CPU跑到N\*100%

结论：

N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N\*(x+y)/x，能让CPU的利用率最大化。

经验：

一般来说，非CPU密集型的业务（加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务），瓶颈都在后端数据库，本地CPU计算的时间很少，所以设置几十或者几百个工作线程也都是可能的。

## **六、结论** ##

N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N\*(x+y)/x，能让CPU的利用率最大化。

[format_png]: /images/20210920/118fc6f376b345458d0e5ddd4eb57131.png
[format_png 1]: /images/20210920/0c04db7c6d7b467f937db7bc5b1e438a.png
[format_png 2]: /images/20210920/3f958e43fe77481184b5ffc9f4288ed6.png
[format_png 3]: /images/20210920/a8d385ff7aa34c609f866bbd2beb7249.png
[format_png 4]: /images/20210920/323d86413fcc4c478c29e389094639ef.png
[format_png 5]: /images/20210920/922a15e8b0b6459fa40803a92088a5cf.png
[format_png 6]: /images/20210920/844d66f848c14cbe8b10b42e94b1b422.png
[format_png 7]: /images/20210920/a2575afb11044fb881b8b47ce7311864.png
[format_png 8]: /images/20210920/8d356916eede4b539f4caf0641f9bc41.png
[format_png 9]: /images/20210920/a69db93a516e4c04be03069814a06f90.png
[format_png 10]: /images/20210920/ee5fb93acfe74430bd4f919929682da0.png
[format_png 11]: /images/20210920/4e54ce49d5294e8495eac357a67ba750.png
[format_png 12]: /images/20210920/200dcaf2a5854ae09de8db86cd853e1a.png
[format_png 13]: /images/20210920/9d6952cf4a7f45ed9902e8ffa761b030.png
[format_png 14]: /images/20210920/c66e3d07a87d4d1a86bf7db5b7861f66.png
[format_png 15]: /images/20210920/3cddbc21575c4993b5b5559fa48cd3fc.png
[format_png 16]: /images/20210920/31419d66a123406baa0c14b71689ee91.png
[format_png 17]: /images/20210920/9a8baf29f706407289ad9d663ae86479.png
[format_png 18]: /images/20210920/a85492472c364f358c472abf110860d2.png
[format_png 19]: /images/20210920/c7d0a2202fad4946a8a2f06735a264ac.png
[format_png 20]: /images/20210920/c34d5951deb54db7aa662964e1efb928.png
[format_png 21]: /images/20210920/c58f0fcd1861449995e080abd8464ac7.png
[format_png 22]: /images/20210920/19817eb119a7446b9695d29d4cb60b21.png
[format_png 23]: /images/20210920/82c05a28b4b849bd8e58ba8d25374a32.png
[format_png 24]: /images/20210920/37c6225b4e494eceae740c0dc4a01b98.png
[format_png 25]: /images/20210920/099f370337ac42adbcd443eb7b00295b.png
[format_png 26]: /images/20210920/e119d8eee8d74cd0af8583c6d5de6d5b.png
[format_png 27]: /images/20210920/64a7928e03c547ad9b5d1eb9f99382b6.png
[format_png 28]: /images/20210920/164d6ebc9bd247a79e02c04be3618f24.png
[format_png 29]: /images/20210920/7fc19de28bcb4c5e8688bb31b569e18d.png
[format_png 30]: /images/20210920/b1516473e1414cfb9c0df55ad66d63bf.png
[format_png 31]: /images/20210920/ce5153fe6ef94333920b12bea685c1e2.png
[format_png 32]: /images/20210920/2a7ce1a1e4b2405db1088fa5c201c1b6.png
[format_png 33]: /images/20210920/facabce4b2dc4e7fb304523a69f5eebf.png