大流量高并发篇

高并发场景
淘宝双十一
春运抢票
微博大V热点信息
疫情口罩抢购系统
秒杀活动系统
高并发系统特点
大流量
PV：page view，某个页面浏览量或点击量。
UV：unique visitor，通过互联网访问、浏览某个网页的自然人。
IP：Internet Protocol，独立IP是指访问过某站点的IP总数，以用户的IP地址作为统计依据。
VV：visit view，访客一天内访问网站的次数。当访客完成所有浏览并最终关掉该网站的所有页面时便完成了一次访问。
PV与VV的区别：PV指页面的浏览次数；VV指的是访问网站的次数。
QPS：query per second，每秒查询数
RPS：request per second，每秒请求数
TPS：transaction per second，每秒事务数
高可用：
系统7 * 24 小时不间断服务。
大数据量：
流量大，自然数据量就大。随之而来的就是，数据的存储压力也会大。
网络复杂：
流量大，数据量大，那么用户的情况就很复杂，三教九流，鱼龙混杂，用户的地址分布也会很广泛，那么就造成了大型网站所面临的网络环境的复杂性。一个网站要做一个省的生意，用户就在这个省里面；一个网站要做一个国家的生意，用户就在这个国家里面，用户就会来源于这个国家的各个省；一个网站要做全世界的生意，用户会来源于全世界，来源于全世界各个国家。网站的等级每升高一级，网络的复杂性也会上升一个量级。
网络安全问题：
既然网络复杂，就难免会出现网络的安全问题。树大招风，枪打出头鸟。网站做大了，就会有很多人惦记和攻击。
需求迭代快速：
用户量大了，市场大了，难免就会有各种各样的需求。
需求一多，对迭代的速度也会要求更高。
所以现在敏捷开发的概念也应运而生。大型网站的产品一般都是每周定时发布。
高并发系统评价指标
高新能
高可用
易伸缩
易扩展
安全性
高并发系统常用手段
分层
单一职责原则
分割
分割的结果就是微服务
分布式
何为分布式？将不同模块部署到不同的服务器上，通过远程调用协调工作。
带来的问题：分布式锁、分布式事务、分布式ID、远程调用通过网络带来的性能问题、某台服务器宕机带来的雪崩效应。
集群
何为集群？多台服务器部署相同的应用，通过负载均衡调度服务器共同对外提供服务。
缓存
CDN：主要用来缓存一些静态资源。
反向代理服务器：也是用来缓存一些静态资源，Nginx就是一个典型的反向代理服务器。
本地缓存：这里的本地指的是应用服务器本地。
分布式缓存：大量的缓存数据，redis集群。
为什么需要使用多级缓存？分而治之，容量问题，根据具体的业务需求对每一处的数据选择最合适的缓存。
使用缓存的前提条件：数据访问频率不均衡，80%的访问集中在20%的数据上；数据的某种状态在某个时间段内有效，不会立刻过期。
异步
消息队列
生产者消费者模式
异步的优点：提高可用性，消费者出问题，一段时期内不影响生产者；提高吞吐量，生产者处理完直接返回；高并发流量削峰，消息队列起到了一个缓冲的作用。
异步的缺点：可以异步做的业务才可以做成异步，实时性要求高的业务不能做成异步。
冗余
冗余是实现网站高可用的必备手段
服务冗余
数据冗余
数据库的冷备份和热备份。冷：离线；热：在线。全球灾备数据中心。
自动化的持续集成、测试、发布、部署、监控
目前的容器化技术docker + k8s较好地实现了自动化的思想。
网站安全问题
密码
手机验证码
对称加密和非对称加密
图形验证码
编码解码
过滤敏感信息
涉及到金钱的风险控制策略
问题点
在考虑扩展性的时候，服务和数据库有什么区别？
服务可以设计成无状态的，但是数据库一定是有状态的。
纵向扩展与横向扩展有什么区别？
纵向扩展是指提升单机的处理能力：加内存、加CPU核数、加存储磁盘，使用缓存，使用异步等
横向扩展：集群部署
提高网站系统伸缩性的手段有哪些？
根据功能将系统进行物理分离，以微服务为单位，每一个微服务实现一个独立单一功能，不同的微服务部署在不同的服务器上。
同一个单一功能的微服务，部署在多台机器上，构成一个集群。
根据业务功能进行物理分离分为两种：纵向分离（分层加分离，垂直分离）和横向分离（平等的业务之间进行分离，水平分离）。
负载均衡是实现网站伸缩性的关键技术。
缓存服务器靠什么来保证系统的伸缩性？
一致性hash算法
关系型数据库如何保证系统的伸缩性？
NoSQL数据库如何保证系统的伸缩性？
伸缩性和扩展性有什么区别？
提高系统扩展性的手段有哪些？
模块化、分层、服务拆分、消息中间件、服务治理
保证系统的安全性有哪些手段？
系统某些业务场景需要保证幂等性，如何实现？
幂等性：对于同一笔业务，执行一次和多次产生的结果是一样的。
场景：某电商平台使用支付宝支付，支付宝支付完成后，直接返回结果给用户界面，而把结果以异步的形式通知给该电商平台。而由于网络问题，支付宝系统可能给该电商平台发送多条通知信息。
多次请求重复处理的原因是在并发的情况下，没有进行幂等性的设计。
解决方法为：加锁，使并发并行变成串行执行。乐观锁，加版本号，更新数据的时候需要校验版本号；分布式锁，分布式锁有多种实现方式，在另外的文章里面再做研究。
一些查询资料的网站
https://help.aliyun.com/
熔断和降级有什么区别？
触发的条件不同：熔断是由于被调用的某个下游服务宕机，放弃对其调用，不要让其拖垮其他服务，可以类比于生活中的保险丝，一般是被动熔断；降级是指从全局整体的角度考虑，考虑到资源有限，为保障系统的核心服务可用，放弃一些外围服务或者是次要服务，就是丢车保帅，属于主动降级。
管理对象的层次不同：熔断是服务级别的，每一个微服务都要做，没有层次之分；而降级是从整体的系统级别来考虑的，对服务要分核心服务和外围服务，降级要从最外围的服务开始。
实现的方式不同。熔断现在有开源的组件如hystrix或者是sentinel可以实现；降级则有很多中策略，如页面降级（原来是异步动态渲染的，改为渲染静态页面）、服务读降级（原来读DB、改为读内存缓存）、服务写降级（原来写DB，改为写内存）、利用风控系统识别机器人爬虫并对其拒绝服务。
XSS和CSRF有什么区别？
XSS指的是在正常用户请求中执行了黑客注入的恶意代码，并且用户数据没有经过过滤和转义。
CSRF指的是冒充别人的登录信息，问题在于没有防范不信任的调用。
提升QPS的常用手段有哪些？两个方向：提高并发数、减少响应时间。
增加各种连接数，redis、mysql、tomcat等等连接数
服务做成无状态，便于横向扩展
代码层面提升效率
能用多线程的地方，用多线程。线程数 = CPU可用核数 / (1 - 阻塞因子)。阻塞因子：CPU密集型趋近于0，IO密集型趋近于1。
服务能力对等，不要让服务端各节点负载倾斜（serviceUrl打乱顺序）
能用缓存的地方用缓存（减少IO）
能用异步的地方用异步（最终一致性，例：发邮件，发通知）
减少调用链
数据多的时候，分批次调用
数据库优化
长连接（要根据业务场景，一般游戏用长连接，需要限制一个服务的连接人数）
如何设计一个秒杀系统？
要充分考虑到秒杀系统的业务场景：参与秒杀活动的用户很多，但是商品的数量是极其有限的，千军万马过独木桥，能坚持到最后的人并不多。所以秒杀系统的设计首要关键点是层层设防，多层阻击，逐步对流量进行过滤。
活动未开始时，前端页面的提交button需要被置灰，设置为不可用的状态，防止在活动开始前产生无效的流量。
前端设置验证码或者是答题环节，防止出现瞬间超高流量。
增加校验：用户参与条件、用户白名单、用户终端、IP地址、参与活动次数、黑名单用户。
非法请求拦截，比如答题时间需要1分钟，因此小于40秒的用户就可以直接拦截掉。
限流：针对秒杀商品的库存量和秒杀活动可能持续的时间可以做限流。
除了从业务上对流量进行过滤，使其成为一个漏斗形，把无效的大部分的流量拦截在后端系统之前，还要从技术上对系统进行一些优化手段。
页面静态化，针对活动页面做静态化处理，缓存到CDN中。原则上，能做成静态页面的一律做成静态页面。
缓存预热，在这样高并发的系统设计中，是离不开redis的，可以提前将一些活动相关的数据预热缓存在redis中，活动开始后，所有的查询都优先走redis缓存查询。
停掉一些外围非核心的服务，比如优惠券、红包、积分、评价等等这些，相当于是服务降级，把资源集中优先供给给当前的秒杀系统。
如何防止超卖？下单即扣库存，redis缓存和数据库库存同时扣，数据库乐观锁，服务端针对同一ID的商品请求做队列串行化处理。
一些设计流程上的保障点：熔断、限流、降级、监控、演练、核对、预案。
后续操作：数据统计、前端埋点、数据分析、数组看板展示。
————————————————
版权声明：本文为CSDN博主「OneMoreWhy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/OneMoreWhy/article/details/107746225