如何设计一个高并发系统 高并发系统设计主要原则
一篇好的文章需要好好的打磨，你现在浏览的文章是一篇关于如何设计一个高并发系统 高并发系统设计主要原则的文章，本文对文章如何设计一个高并发系统 高并发系统设计主要原则好好的分析和解答，希望你能喜欢，只有你喜欢的内容存在，只有你来光临，我们才能继续前行。
架构高可用高并发系统的设计原则
通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨菲定律、康威定律和二八定律三大定律，而系统设计包括高并发原则、高可用和业务设计原则等。
架构设计三大定律
墨菲定律 – 任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生
康威定律 – 系统架构师公司组织架构的反映 – 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 – 如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 – 微服务架构的理论基础 – 康威定律https://yq.aliyun.com/articles/8611– 每个架构师都应该研究下康威定律http://36kr.com/p/.html
二八定律 – 80%的结果取决于20%的原因
系统设计遵循的原则
1.高并发原则
无状态
无状态应用，便于水平扩展
有状态配置可通过配置中心实现无状态
实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系统维度：按照系统功能、业务拆分，如购物车，结算，订单等
功能维度：对系统功能在做细粒度拆分
读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统
模块维度：对整体代码结构划分Web、Service、DAO
服务化
服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服
消息队列
目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等
大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)
数据校对: 解决异步消息机制下消息丢失问题
数据异构
数据异构: 通过消息队列机制接收数据变更，原子化存储
数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环
缓存银弹
用户层:
DNS缓存
浏览器DNS缓存
操作系统DNS缓存
本地DNS服务商缓存
DNS服务器缓存
客户端缓存
浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)
App客户缓存(js/css/image…)
代理层：
CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)
接入层：
Opcache： 缓存PHP的Opcodes
Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 业务数据缓存
Nginx为例：
PHP为例：
应用层：
页面静态化
业务数据缓存(Redis/Memcached/本地文件等)
消息队列
数据层：
NoSQL： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系统层：
CPU : L1/L2/L3 Cache/NUMA
内存
磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存
并发化
2.高可用原则
降级
降级开关集中化管理：将开关配置信息推送到各个应用
可降级的多级读服务：如服务调用降级为只读本地缓存
开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略
业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能
限流
目的: 防止恶意请求攻击或超出系统峰值
实践：
恶意请求流量只访问到Cache
穿透后端应用的流量使用Nginx的limit处理
恶意IP使用Nginx Deny策略或者iptables拒绝
切流量
目的：屏蔽故障机器
实践:
DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢
HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
LVS/HaProxy/Nginx: 摘除故障节点
可回滚
发布版本失败时可随时快速回退到上一个稳定版本
3.业务设计原则
防重设计
幂等设计
流程定义
状态与状态机
后台系统操作可反馈
后台系统审批化
文档注释
备份
4.总结
先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。
本文作者为网易高级运维工程师
怎样具备大规模高并发访问的Web应用架构设计和开发经验
理论上经验这个东西是学不来的.
说一下我的例子.
刚入行的时候,基本就是写了一些增删改查.甚至session都不太理解.
随着入行后,你会遇到各种各样的问题.在解决问题的过程中,经验来了.
简单说一下所谓大规模高并发访问的web架构吧.
其实,对于大规模高并发不外乎两点,第一点是及时相应(尽可能优化io).第二点是数据安全.
这两点控制的好,就没问题的.所以,我们的架构也就围绕在这两点应运而生.
第一点,为了尽可能提高应用的io吞吐量.则需要我们把所有耗时的io操作尽可能的优化,比如全局使用很少更改的一些配置,则可以采用nosql来全局共享(注意,这里的全局是指服务器集群.如果涉及到了大规模,肯定是多服务器的).在其次可以增加服务器缓存.比如2秒钟从上一条的服务器读取配置,存到服务器级别.以提高效率.还有线程缓存.如果业务复杂可能对一个请求需要查询多次数据,不变的,老规矩,放到线程缓存.基本也就差不多了.
第二点,因为应用不同,要考虑容错率.这个部分优化,可以考虑分离业务,把必须要数据安全的业务逻辑提取出来,队列执行或者特殊处理.
剩下的就是服务器部署与如何分配,比如多少台web服务器,数据库配置,内存服务器配置等.
这只能是在实际项目和工作过程中来区别对待了.
(二)微信红包高并发系统设计方案(1)
2021年1月28日，正月初一，微信公布了用户在除夕当天收发微信红包的数量——142亿个，而其收发峰值也已达到76万每秒。百亿级别的红包，如何保障并发性能与资金安全？这给微信带来了超级挑战。面对挑战，微信红包在分析了业界“秒杀”系统解决方案的基础上，采用了 SET化、请求排队串行化、双维度分库表 等设计，形成了独特的高并发、资金安全系统解决方案。实践证明，该方案表现稳定，且实现了除夕夜系统零故障运行。概要：
一、业务 特点 ：海量的并发要求；严格的安全级别
二、技术 难点 ：并发请求抢锁；事务级操作量级大；事务性要求严格
三、解决高并发问题 通常 使用的 方案 ：
1.使用内存操作替代实时的DB事务操作（优点：内存操作替代磁盘操作，提高了并发性能。）
2使用乐观锁替代悲观锁。应用于微信红包系统，则会存在下面三个问题：滚并返回失败；并发大失败，小成功。DB压力大。
四、微信 红包 系统的高并发解决 方案 ：
1.系统垂直SET化，分而治之。
2.逻辑Server层将请求排队，解决DB并发问题。
3.双维度库表设计，保障系统性能稳定
类似“秒杀”活动，群里发一个红包=“秒杀”商品上架；抢红包的动作=“秒杀”的查询库存；拆红包=“秒杀”
同一时间有10万个群里的用户同时在发红包，那就相当于同一时间有10万个“秒杀”活动发布出去。10万个微信群里的用户同时抢红包，将产生海量的并发请求。
微信红包是微信支付的一个商户，提供资金流转服务。
用户发红包=购买一笔“钱”（在微信红包这个商户上），并且收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。
该系统由接入层、逻辑服务层、存储层与缓存构成。Proxy处理请求接入，Server承载主要的业务逻辑，Cache用于缓存库存数量、DB则用于数据持久化。
一个“秒杀”活动，对应DB中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于DB中库存的操作上。一般来说，对DB的操作流程有以下三步：
a. 锁库存
b. 插入“秒杀”记录
c. 更新库存
a.锁库存是为了 避免 并发请求时出现“ 超卖 ”情况。同时要求这 三步操作 需要在 一个事务 中完成(难点:并发请求抢锁)。
第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要 排队等待 。同时参与“秒杀”的用户越多，并发进DB的请求越多，请求 排队越严重 。
红包系统的设计上， 除了并发请求抢锁之外，还有以下两个突出难点 ：
首先，事务级操作量级大 。上文介绍微信红包业务特点时提到，普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就是有数以万计的“并发请求抢锁”同时在进行。这使 得DB的压力 比普通单个商品“库存”被锁要大很多倍。
其次，事务性要求严格 。微信红包系统本质上是一个资金交易系统，相比普通商品“秒杀”系统有更高的事务级别要求。
普通商品“秒杀”活动系统，解决高并发问题的方案，大体有以下几种：
如图2所示，将“实时扣库存”的行为上移到 内存Cache中操作 ，内存Cache操作成功直接给Server返回成功，然后 异步落DB持久化 。
优点：提高了并发性能。
缺点： 在内存操作 成功 但 DB持久化失败 ，或者内存 Cache故障 的情况下，DB持久化会 丢数据 ，不适合微信红包这种资金交易系统。
商品“秒杀”系统中，乐观锁的具体应用方法，是在DB的“库存”记录中维护一个版本号。在更新“库存”的操作进行前，先去DB获取当前版本号。在更新库存的事务提交时，检查该版本号是否已被其他事务修改。如果版本没被修改，则提交事务，且版本号加1；如果版本号已经被其他事务修改，则回滚事务，并给上层报错。
这个方案解决了“并发请求抢锁”的问题，可以提高DB的并发处理能力。
应用于微信红包系统，则会存在下面三个问题 ：
1.在并发抢到相同版本号的拆红包请求中， 只有一个能拆红包成功 ， 其他的请求 将事务回滚并返回失败，给用户 报错 ，用户体验完全不可接受。
2.将会导致 第一时间 同时拆红包的用户有一部分直接 返回失败 ，反而那些“ 手慢 ”的用户，有可能因为 并发减小 后拆红包 成功 ，这会带来用户体验上的负面影响。
3.会带来 大数量 的 无效 更新 请求 、事务 回滚 ，给 DB 造成不必要的额外 压力 。
微信红包用户发一个红包时，微信红包系统生成一个ID作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作，都根据这个ID关联。
红包系统根据这个红包ID，按一定的规则（如按ID尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑Server服务器、DB统称为一个SET。
这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。
红包系统是资金交易系统，DB操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达DB的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。
按这个思路，为了使拆红包的事务操作串行地进入DB，只需要将请求在 Server层以FIFO （ 先进先出 ）的方式排队，就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
首先，将同一个红包ID的所有请求stick到同一台Server。
上面SET化方案已经介绍，同个红包ID的所有请求，按红包ID stick到同个SET中。不过在同个SET中，会存在多台Server服务器同时连接同一台DB（基于容灾、性能考虑，需要多台Server互备、均衡压力）。
其次，设计单机请求排队方案。
最后，增加memcached控制并发。
为了 防止 Server中的请求队列过载导致队列被降级，从而所有请求 拥进DB ，系统增加了与Server服务器同机部署的 memcached ，用于控制拆同一个红包的 请求并发数 。
具体来说，利用memcached的 CAS原子累增操作 ，控制同时进入 DB执行拆红包事务的请求数 ，超过预先设定数值则 直接拒绝服务 。用于 DB负载升高时的降级 体验。
通过以上三个措施，系统有效地 控制了DB的“并发抢锁” 情况。
红包系统的分库表规则，初期是根据 红包ID的hash值 分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而DB的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB性能会有大幅度下降，影响系统性能稳定性。采用 冷热分离 ，将历史冷数据与当前热数据分开存储，可以解决这个问题。
系统在以 红包ID维度 分库表的基础上，增加了以 循环天分表的维度 ，形成了 双维度分库表 的特色。
具体来说，就是分库表规则像db_xx.t_y_dd设计，其中，xx/y是红包ID的 hash值后三位 ，dd的取值范围在01~31，代表一个月天数最多 31 天。
通过这种双维度分库表方式，解决了DB单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。
综上所述，微信红包系统在解决高并发问题上的设计，主要采用了SET化分治、请求排队、双维度分库表等方案，使得单组DB的并发性能 提升了8倍 左右，取得了很好的效果。
http://www.infoq.com/cn/articles/2017hongbao-weixin
以上内容是小编精心整理的关于如何设计一个高并发系统 高并发系统设计主要原则的精彩内容，好的文章需要你的分享，喜欢如何设计一个高并发系统 高并发系统设计主要原则这篇精彩文章的，请您经常光顾吧！