架构设计：高并发读取，高并发写入，并发设计规划落地方案思考
互联网应用架构：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。
前言
架构设计在应用中是针对所有重要问题作出的重要决策，最开始的源头就是计算机里面的读和写。在面对大型的网站或者业务系统的时候，一些理所当然的行为或者操作在高并发下就变得脆弱不堪。
并发有几种
- 高并发读取
- 高并发写入
在很多同学的了解中，高并发更多局限在高并发读取里面，概念中并没有遇到高并发写入的问题，当遇到高并发问题的时候，集群，负载，读写分离，分库分表，但其实不然，面对不同类型的高并发所采用的处理方案并不一致，根据不同的场景在设计不同的架构。
任何一个网站，面对这大量的C端用户的时候，不可能是单纯的读取数据或者写入数据，肯定是读写混合着交织在一起，对于C端的用户来说，肯定更加侧重读取数据的用户体验，写入毕竟是少量的需求，对于后台处理系统来说，高效写入才是我们重中之重。
分库分表设计理念参考：《微服务手册：分库分表从分析到实践，不再停留只会说分库分表》
高并发读取策略
1、“缓存”策略
在面对高并发读取的时候，很多时候想到的第一件事就是加缓存，但是笔者里面的缓存并不是简单加入缓存，而是一种策略。
1.1、加入实体缓存
这个就是我们经常使用的一种方案，采用本地缓存或者缓存中间件来实现《微服务手册：高速查询？除了Redis我们还有另外的选择》，这些是非常成熟的方案，但是对于缓存，我们需要考虑一下几点问题：缓存雪崩，缓存穿透，缓存大量的热点key过期。虽然有存在这些问题存在，但是我们在处理这些问题本质上来说都是缓存回源问题，可以采用不回源策略来解决这些问题，只查缓存，但是这些就需要主动更新缓存，如果采用回源呢？量能一起来就很容易遇到上面的问题，这些网上都有比较多的方案可以借鉴参考。
1.2、数据库主从分离
上面的实体缓存虽然可以帮助我们解决很多问题，但是面对一些很复杂的业务场景的时候，单纯的key，value并不能满足我们的需求，后台的运营系统需要更加复杂的业务逻辑及业务数据，如果此时我们只有一个数据库，所有的业务查询都是走同一个数据库，会影响C端用户的高并发访问，此时我们有一个快捷的解决方案：直接加上一个或者多个Slave，从而减轻主数据库的压力。
1.3、动静分离
现在基本上都是BS的天下，那内容基本上就分为静态内容与动态内容。
静态内容基本上啥都不变，图片、HTML、JS、CSS文件等，对用户来说几乎不变，此时我们可以把这些内容采用CDN策略来实现从而实现高速访问。
动态内容接口方式返回给用户。
2、并发策略
上面的无论怎么做，基本上都是串行操作，现在来说说如何做并行计算。
2.1、异步PRC或者HTTP请求
现在很多RPC框架或者HTTP客户端，都支持异步的方式，对于多个请求可以采用异步方式同时请求并进行数据聚合就行。
2.2、冗余服务器
这个有点难以理解并且实际中很难用到，用户发送一个请求，后端有多台服务器等待着，先一台服务器处理如果没有在规定的时间内返回数据则废弃掉，直接请求第二台，以此类推。是不是听起来很像轮训，不过那么多的冗余服务器也是大工程。
3、重写轻读策略
这里是一个非常重要的拓展，按照一定的业务规则把关联数据计算完成，在读取的时候直接去这个地方读取就行，这是聚合存储的概念，可以采用缓存，数据库，ES等。有兴趣的同学可以了解一下微博的Feeds流
4、总结
上面的三种方案，无论怎么做本质上来说都是读写分离的实现。
高并发写入策略
1、数据分片策略
数据分片非常好理解，把要处理的数据分成N份并行进行处理，像我们数据库的分库分表，可以充分利用计算机的CPU或者内存等资源。JAVA里面的ConcurrentHashMap，kafka的partition，es的分布式索引都是此类策略的实现。
2、任务分片策略
相比于数据分片，任务分片更侧重于在程序上进行并行。在程序层面，像map/reduce就是典型的
任务分片。
3、异步策略
异步主要从4个层面来分析，分别是系统层面，JDK层面，接口层面，业务层面，针对不同的层面，采用不同的异步方式进行操作，例如接口层面的请求，我们可以采用okhttp，默认支持异步请求。
4、汇总批量策略
很多同学在进行数据操作的时候都有一个经验，数据库一条一条插入是非常费劲的，每次都要进行一次操作，有100份数据的话，就需要进行100份的操作，这样子的行为非常浪费时间，那解决方案就是采用数据汇总并进行批量操作。例如我们mysql里面，多个小事务合并成一个进行操作。
总结
高并发是一个复杂的问题，本文只是列出个大概，具体每一个小项都是一个值得深入研究的方向。
--END--
作者：@互联网应用架构
原创作品，抄袭必究
如需要源码或请转发，关注后私信我
部分图片或代码来源网络，如侵权请联系删除，谢谢！