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

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

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

 

欢迎关注博客园麦小逗，小逗与你同在

 

 

---

 

    本质很简单，一个是慢，一个是等。两者是相互关联的，因为慢，所以要等，因为等，所以慢，解决了慢也就解决了等，反之亦然。

    关键是如何解决慢和等，核心一个是短，一个是少，一个是分流。

    短是指路径要短。典型的MVC结构是请求->controller->model->view，然后把页面返回给用户。下面分别介绍三个核心。

 短

 

 

    1.页面静态化 -- 用户可以直接获取页面，不用走那么多流程，比较适用于不频繁更新的页面，比如登录页、表单页等。

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

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

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

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

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

 少

 

 

   少是指查询的数据要少。

    1.分表 -- 把本来同一张表的内容，可以按照地区、类别等分成多张表，很简单的一个思路，但是要尽量避免分出来的多表关联查询。

    2.分离活跃数据 -- 例如登录用户业务，注册用户很多，但是活跃的登录用户很少，可以把活跃用户专门保存一张表，查询是先查询活跃表，没有的话再查总表，这也类似于缓存啦。

    3.分块 -- 数据库层面的优化，对程序是透明的，查询大数据只用找到相应块就行啦。

分流

 

 

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

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

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

 

THE END

欢迎各位攻城狮指正修改，也可微信搜索微信号amcdulls，或程小白，同步更新博文

转载自http://www.cnblogs.com/New-Zealand/p/5165663.html