高并发系统的理解

第一:我们设计高并发系统的前提是该系统要高可用，起码整体上的高可用。
第二:高并发系统需要面对很大的流量冲击，包括瞬时的流量和黑客攻击等
第三:高并发系统常见的需要考虑的问题，如内存不足的问题，服务抖动的问题、磁盘不足的问题、网络带宽的问题、突发流量的问题、面对黑客攻击的问题

高并发的架构设计

1. 垂直拆分业务
   一个大型的系统业务相对复杂，不同的业务需要面对的流量压力也不同。我们可以根据不同的业务垂直拆分业务(DDD),我们可以根据业务拆也可以根据机器的特性拆服务，这些就要看具体的业务和系统运营方向。
   微服务拆分需要把一个单体的应用，按照一定的维度(业务域的维度、机器特性的维度等等)拆分成多个服务模块。
   例如:电商系统拆分成用户系统、订单系统、商品系统。

2. 数据的垂直和水平拆分+分库分表

网络请求的流量虽然可以通过缓存，mq的削峰等缓解压力，但最终数据部分的压力还是会压到数据库上。数据库的垂直拆分主要是根据我们上面的垂直拆分业务后，根据对应模块的业务做对应的数据库设计。
我们分库还有一个原则就是一个数据库实例操作数据的瓶颈受到数据库引擎程序执行的瓶颈影响，所以在高并发的环境下，做好了垂直拆分的数据库，如果一个数据库实例承载不了并发的情况下，我们也要做水平拆分，一般会根据主键hash求模或数值型主键求模做水平拆分。
分表的场景主要面对单表数据库过大的场景使用。
数据库的分库分表主要使用mycat(由于做的不是很完善，特别是跨库查询的问题用的人越来越少，sharding jdbc(目前主流的用法))。

3. 数据库的读写分离、双主等
   在高并发的场景中，我们单库能够承载1000左右的tps，如果并发太高对数据库的压力就会很大。不过我们的业务一般都是读多写少的场景，这个时候我们可以考虑数据库的一主多备的部署，读操作从备库中读取。
   还有我们的系统后台管理，经常会有慢sql查询，这些可以单独拿出来备库做后管的操作。防止一些复杂查询造成数据库的整体性能的下降。
   数据库的主从复制是通过binlog同步的，如果考虑到高可用也可以做双主HA的部署方式。这个要看具体的业务场景。

4. 连接池

应用程序从存储中获取数据需要建立连接，我们需要使用连接池。例如:数据库连接池、redis连接池，线程池。

5. 缓存
   缓存是我们我们设计高并发系统常用的手段。缓存的使用主要是提升系统的整体访问性能。缓存的思想在其他的设计上也大量被使用，比如cpu的设计、操作系统、web应用、浏览器等等都大量使用到缓存。
   设计高并发的系统常用的缓存有:redis缓存、JVM本地缓存(堆内存需要程序处理)，nginx本地缓存、memcached、CDN静态资源的缓存等。

使用缓存需要注意以下几点的问题:
缓存与数据库数据一致性的问题(延迟双删)
缓存雪崩的问题(缓存大面积的失效，或者redis宕机等):设置redis的缓存有效时间的均匀分布、数据的预热(多应对突发事件，比如热点新闻)，redis服务的高可用部署
缓存的击穿问题:一个redis的key失效后，大量请求的涌入到数据库，造成数据库的压力。设置热点数据的过期时间、定时更新策略，锁操作(如果请求拿不到Key先锁住，等数据放入缓存再释放锁)
缓存穿透问题:用户请求的数据缓存和数据库中都没有，但是请求依然不断的涌入，对数据库造成的压力。对于穿透问题，我们可以在业务层先校验，数据库中没有的数据设置在缓存中设置过期时间，该时间内不在请求到数据库

CDN静态资源缓存:将静态的资源放到位于多个物理位置的机房，用户访问静态资源的时候访问到就近的机器，加快了访问速度。

6. 异步，mq削峰

我们的系统在做一些活动的时候，会产生一些瞬时的高峰流量，这些请求如果直接和数据库交互处理业务的时候会把数据库压垮。我们把请求发送到mq中通过异步处理的方式，减轻瞬时流量带来的冲击。当然mq还有分布式解耦等其他使用场景，这里不做细说。

7. 熔断

熔断是保护系统稳定性的一种手段，在流量比较大的情况下，会出现部分服务的性能瓶颈造成整个服务不可用的情况。例如由于某一个慢sql降低了数据库的性能，其他请求积压过来，数据库的引擎程序处理不了造成数据库的假死。再造成整个服务不可用的情况。这个时候我们就需要采用熔断的手段，比如系统响应时间过慢后来的请求就会转发到错误页面。我们可以使用springcloud 的hystrix组件来做熔断

8. 限流

由于我们的系统会有短暂的峰值请求流量进来，我们的CPU，内存，线程数据库在面临短暂的流量高峰无法应对的时候，需要做限流的设置。前面我们讲到一些分布式限流的算法。这里就不再详细叙述。

9. 扩容
   如果我们的产品随着营运力度的加大，用户不断的增长，原理部署了5台服务器已经满足不了业务的发展。所以在架构设计之初就要考虑到系统支持动态的扩容的功能。比如我们的sharding jdbc支持数据库的动态扩容，还要考虑生成id的策略，是否支持为了增加机器即可的架构方案，我们从单机房部署到多机房部署时是否能平滑扩容。编码能不能支持。特别注意一点就是我们的架构设计中的状态保持和水平扩展库之后原先的数据是否能正常读取的问题

10. 海量数据的处理问题
    面对大量的数据搜索一般使用elasticsearch，es本身就支持动态的扩容。大数据的存储一般用到hbase、clickhouse等。