看过年人流高峰，浅聊并发之战[架构篇]

　　引语：人多是好事！人多好赚钱。不过这对于技术人员来说，却也不是一个小问题，我对这种问题一直是抱以一颗敬畏之心的。这更多的是一个架构问题，作为一个开发我也就这点见识了！看着微信、支付宝等等大公司发着几个亿的红包的，我急红了眼，不是因为我错过了几个亿（实际上我基本一点都没抢到），而是羡慕他们技术上的牛掰！面对几亿人的冲击，他们巍然不动，稳稳地服务着大众人民。为此，我想写一篇关于高并发方面的文章了（大数据就不说了），希望借以抛砖引玉！

　　声明：本文的主要创作方式为些许的个人经验加上网上资料的收集，并非所以都为本人亲身经历，但绝对是干货（至少我是这么认为的），希望对大家有一点点的帮助，也强烈欢迎指教！

　　并发是个最常见的但是不见得都需要处理的问题。它的解决不是一点，而是一系列基础设施的配合操作完成的，我们可以不必去处理，或者只需巧妙的避开他就可以了。但是，你应该要了解大名鼎鼎的他。并发就是同一时间访问某个服务所产生的效果。

　　并发可能导致以下几个问题：

　　　　1. 写文件错误，如多写、少写、错写（严重）

　　　　2. 数据存储读取错误，如已经产生的效果没有立即获取（客户立马就不高兴了）

　　　　3. 服务器响应变慢，如有些需要系统自动等待锁操作（稍慢可以接受）

　　　　4. 服务器直接挂掉，某些操作不当导致服务器资源耗尽只有挂掉了（你完了）

　　发现需要解决的问题，那就对症下药吧。

　　1. 写文件。这种场景基本上是在于记录日志一类的操作吧，平时没有什么实际用处，但是真的到了出事的时候，就尤其需要了，里面会记录一些操作记录，特殊操作结果情况等等。一般来说，这种文件都是以追加的形式进行写入文件的，但是因为都是写一个文件，如果同时操作，可能就会出现各种难以预料的事。当然，可能最多就是某用户写的日志被另一个给覆盖了，少一两条也话没什么关系，我最开始也是这么认为的。但是，这也是在我们的预料之中，预料之外的事鬼知道呢，我就曾经因为写日志把整个服务给整挂掉了你信不？还是，加锁吧，看情况，加读锁、写锁，慢就慢一点吧，准确性安全性放第一吧！

　　2. 数据错误。这绝对是致命的，如果数据出问题了，没有给客户作好解释，基本上就是，能赔多少就赔多少，赔不了咱们就关门歇业吧！说句行外话，人们所有的操作，不都是基于对系统数据的相信吗？如果数据都错了，那谁还敢再用，毕竟，他什么也没有干啊，所有的东西都显得那么科幻！那么，并发下，我们可以做什么呢？1. 数据库该有的唯一键一定要加上（即使其他都错了也不能让真数据写进去）；2. 针对特殊业务采用不同特点的数据库，一般应对高并发都要求处理速度极快，所以nosql内存数据库就是必须的了；3. 在保证数据准确的同时尽量使用查询缓存；4. 一些耗时的不需要实时的操作，仍给队列慢慢去做吧！

　　3. 服务器响应慢，这个嘛，一般是通过负载均衡，分布式服务搞定的，代码里做到尽量最优化，如果还是承受不住的话，那就加机器吧！

　　4. 服务器实在受不了，挂掉了，在没有影响数据准确性的情况下，重启继续干活（如果你敢的话）！

　　5. 既然已经考虑到了并发的问题，我想，如果事情看起来有可能发生，那就一定会发生。做好备用方案、备用设备、紧急恢复措施可能是最重要的吧！迟早会派上用场的！

　　好吧，我感觉我已经没有其他话可说了（黔驴技穷），一个字，没那么简单。给几个参考链接吧！

　　微信红包的系统设计&优化(http://djt.qq.com/article/view/1349)

　　混合云架构百科(http://baike.baidu.com/link?url=2MYoWz6cLxpl2qP4dW93UxJm8raufcKFEG8Pi6dtTN0e6FFi97ZE4l_KY-VrrBUaMTvFDZRbe5ccgKTEYxo9bT_GKhRFFiq-0Qy-r4kfx3d6Ia099Eo4qlTU67j00oT7)

　　12306的架构设计与淘宝天猫(http://www.zhenhua.org/article.asp?id=760&utm_source=tuicool&utm_medium=referral)

　　...

　　以上，就算是过年没事干，瞎想吧！平时我们也不会涉及这方面的开发工作，所以也只能靠想像力了。不过，架构师不应该就是这样练成的吗？哈哈，不涉及具体技术，但是真心希望指教！