大数据和高并发的解决方案总结

现在，软件架构变得越来越复杂了，好多技术层出不穷，看得威哥眼花缭乱，解决这个问题呢，就是要把复杂问题简单化，核心就是要把握本质。

软件刚开始的时候是为了实现功能，随着信息量和用户的增多，大数据和高并发成了软件设计必须考虑的问题，那么大数据和高并发本质是什么呢？

威哥在网上也查阅了好些资料，总结了下大数据和高并发的本质：

一个是慢，一个是等。两者是相互关联的，爱恨交织，因为慢，所以要等，因为等，所以慢，解决了慢，也就解决了等，解决了等，也就解决了慢。

那如何解决慢和等呢？

威哥总结了3个核心：

1.短；

2.少；

3.分流；

短：

短是指路径要短。在硬件层面，我们可以把站点通过CDN部署到离客户最近的网络节点入口。

在代码技术层面，例如典型的mvc结构是请求->controller->model->dao->view，然后把页面返回给用户。要想短的话：

1.页面静态化：用户可以直接获取页面，不用走那么多流程，比较适用于页面不频繁更新。

2.使用缓存-：第一次获取数据从数据库准提取，然后保存在缓存中，以后就可以直接从缓存提取数据。不过需要有机制维持缓存和数据库的一致性。

3.使用储存过程：那些处理一次请求需要多次访问数据库的操作，可以把操作整合到储存过程，这样只要一次数据库访问就可以了。

4.批量读取： 高并发情况下，可以把多个请求的查询合并到一次进行，以减少数据库的访问次数。

5.延迟修改：高并发情况下，可以把多次修改请求，先保存在缓存中，然后定时将缓存中的数据保存到数据库中，风险是可能会断电丢失缓存中的数据。

6.延迟落地：延迟落地数据信息，只落地消息信息，比喻外卖平台下单，我们只快速落地下单消息，之后再线下通过其他机制自动处理这一批落地消息，再主动通过消息信息获取到外卖平台的相关接口信息，再在本地操作数据落地。比喻饿了么下单，我们先接受饿了么的下单消息，快速反馈到饿了么App上，提示客户商家已经成功接单，之后通过一个自动服务依据落地的下单消息主动调用饿了么订单接口，之后再处理本地的商品，库存，财务等等相关信息，实现真实订单落地。

7.使用索引 - 索引可以看作是特殊的缓存，尽量使用索引就要求where字句中精确的给出索引列的值。

少：

指服务查询的数据要尽量少。

1.分表：把本来同一张表的内容，可以按照地区，类别或者业务属性等分成多张表，很简单的一个思路，但是要尽量避免分出来的多表关联查询。比喻订单表，包含了订单主表信息，订单购物信息，订单套餐信息，订单金额拆分信息，订单配送信息，订单追踪信息，这样一个大表，要按照业务属性拆分出来，当然为避免多表关联查询，我们可以使用延迟加载方式加载数据，反正要做到每次数据尽可能的少。

2.分离活跃数据：例如登录用户业务，注册用户很多，但是活跃的登录用户很少，可以把活跃用户专门保存一张表，查询是先查询活跃表，没有的话再查总表，这也类似与缓存。威哥再处理妙生活商品时，本周热卖的商品，直接分离出来存储到Redis，不管是APP还是外卖平台，内部收银，ERP系统，去访问这些热卖商品时，我们都是在Redis的一个较小的数据范围去查询。

3.分块： 也可以理解为分区，数据库层面的优化，对程序是透明的，查询大数据只用找到相应块就行。比喻将订单表按照时间范围分成多个时间维度的订单表，可能存储在一个数据库，也可以存着在不同的数据库和不同分布式集群上，但是对外还是显示一张表。

分流：

1.集群：将并发请求分配到不同的服务器上，可以是业务服务器，也可以是数据库服务器。

2.分布式：分布式是把单次请求的多项业务逻辑分配到多个服务器上，这样可以同步处理很多逻辑，一般使用与特别复杂的业务请求。

3.CDN：在域名解析层面的分流，例如将华南地区的用户请求分配到华南的服务器，华中地区的用户请求分配到华中的服务器。