前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案。在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家。服务器架构业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn ,这些都是能让业务程序流畅运行的强大后盾。服务器这块多是需要运维人员来配合搭建,具体我就不多说了,点到为止。大致需要用到的服务器架构如下:?服务器o均衡负载 (如: nginx ,阿里云SLB) o资源监控o分布式?数据库o主从分离,集群oDBA 表优化,索引优化,等o分布式?nosql oredis ?主从分离,集群omongodb ?主从分离,集群omemcache ?主从分离,集群?cdn ohtml ocss ojs oimage 并发测试高并发相关的业务,需要进行并发的测试,通过大量的数据分析评估出整个架构可以支撑的并发量。测试高并发可以使用第三方服务器或者自己测试服务器,利用测试工具进行并发请求测试,分析测试数据得到可以支撑并发数量的评估,这个可以作为一个预警参考,俗话说知己自彼百战不殆。第三方服务 : ?阿里云性能测试并发测试工具:?Apache JMeter ?Visual Studio性能负载测试?Microsoft Web Application Stress Tool 实战方案通用方案日用户流量大,但是比较分散,偶尔会有用户高聚的情况;场景: 用户签到,用户中心,用户订单,等服务器架构图:说明:场景中的这些业务基本是用户进入APP 后会操作到的,除了活动日(618, 双 11 ,等 ),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中DB 的查询;优先查询缓存,如果缓存不存在,再进行DB 查询,将查询结果缓存起来。更新用户相关缓存需要分布式存储,比如使用用户ID 进行 hash 分组,把用户分布到不同的缓存中,这样一个缓存集合的总量不会很大,不会影响查询效率。方案如:?用户签到获取积分o计算出用户分布的key,redis hash中查找用户今日签到信息o如果查询到签到信息,返...