高并发架构

前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分离，集群 DBA 表优化，索引优化，等 分布式 nosql redis 主从分离，集群 mongodb 主从分离，集群 memcache 主从分离，集群 cdn html css js image 并发测试 高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。 测试高并发可以使用第三方服务器或者自己测试服务器

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 从事开发工作两年来，从未写过只言片语，俗话说的好”好记性不如烂笔头“，最近心血来潮开始想慢慢写点博文，不仅是知识的积累还是为了若干年后回头看看当年努力的过程，希望把这个养成习惯并坚持下去，啰嗦了这么久 来点干货把。 之前面试淘点点的时候被问倒得一个问题至今牵挂，由于工作环境的限制，我没能接触到一些大数据量的并发工作，也没能有机遇参与复杂系统的设计，而我学习复杂或高并发系统的唯一途径就是阅读源码，惭愧的是，至今也只阅读了Tomcat的部分源码，于是我在oschina上贴出问题与互联网猿一同分析（ 大家可以先看看问题：关 于淘点点面试中碰到的架构问题 ），非常感谢大家的意见，尤其是@ 林中漫步 @JerryLin 两位先生 最终确定两钟实现思路： 1、 具有排序功能的队列 2、 Redis+定时器 思路 1 原理： 第一种思路也就是大家推荐的延迟队列实现的原理，其就是一个按时间排好序的队列，每次put的时候排序，然后take的时候就计算时间是否过期，如果过期则返回队列第一个元素，否则当前线程阻塞X秒，这个也是JDK 自带 DelayQueue 的思路。详细可看源码 代码实现： 待实现后补充 思路 2 原理： 第二种思路需要利用Redis的有序集合，说到使用 Redis 就不得不考虑Score的设计

1 概述 秒杀系统之所以难做，是因为在极短的时间内涌入大量的请求，来同时访问有限的服务资源，从而造成系统负载压力大，甚至导致系统服务瘫痪以及宕机的可能。本文会介绍秒杀系统中存在的痛点以及针对这些点的优化思路。 2 秒杀系统是什么鬼 如：12306的春节抢票、各大电商搞的定时抢购活动，如小米手机的在线抢购等，抢过火车票的同学都知道在放票的那一瞬间可能1s都不到，票就被抢购一空了。 3 秒杀系统的难点 （1）短时间内高并发，系统负载压力大 （2）竞争的资源有限，数据库锁冲突严重 （3）避免对其他业务的影响 4 常见的互联网分层架构 （1）客户端层：手机或PC端操作的客户端页面，域名通过DNS解析路由到NG （2）反向代理层：一般通过NG作为反向代理，将客户端请求均衡路由到后端站点服务，NG也可以水平扩展为多实例，且每个实例可单独部署为主从的高可用方案。 （3）站点层：站点层可以水平扩展为多个实例部署，以此来均衡来自客户端请求产生的高并发负载，多个web server之间的session信息可以集中存储于分布式缓存服务（Redis，MemCache）中。 （4）服务层：服务层也可水平扩展为多个实例部署，即时下最火的微服务方式 （5）数据库层：数据库层的常见部署方式，如读写分离，分库分表等 5 秒杀系统的架构原则 （1）尽量将请求拦截在上游 对于秒杀系统来说，系统的瓶颈一般在数据库层