分享一位网友的架构杂谈

不容类型的网站，并发处理不一样,例如针对sns这种类型的网站，用户并发量是大，

但是对于事务事务要求不高，所以可以依靠分布式缓存，分布式服务来缓解并发

如果并发量大，现在前端很多都是做集群。  

前端可以使用nginx反向代理，或是lvs，后端对应多个应用服务器 

高并发的处理主要还得靠架构解决，mvc框架解决不了 

nginx和lvs有什么区别: 对后端应用的负载不一样，我公司最高pv时是2000多万，使用2台nginx，没有问题 

进行网络推广时，统计一天最高pv2000万，服务基本正常。查询缓存命中率都比较高

 

如果真的是特别大的并发，想淘宝高活动时，基本依赖于硬件的负载均衡如F5Networks

nginx是可以针对静态资源做缓存，主要是读取数据以缓存为主，并且传输时进行压缩，效率不差

nginx做负载均衡就是实现一个反向代理，将请求分发给后端的应用服务器，所以会缓解并发的压力。但是毕竟是软件

 

以读缓存为主的之前是memcache，现在是redis,memcache不支持持久化，功能、性能都不如redis

缓解写并发可以使用mq，kestrel等队列

 

对于后台这种并发量小的事务使用最基本的都行，就算在方法上加sinchronized对于电商下单一天下个10万单都没问题。

如果并发量大，就要把事务核心部分提取出来，使用异步消息来处理附加功能

如淘宝为了把事务并发做到最大化，并订单表分到了10台数据库服务器上，并且每台服务器还拆分了10张表

而且他把买家和卖家订单查询都分开了

我上面说的redis主要是应对读缓冲的情况，如果不是读缓存，对数据库io压力就会过大