实现
抢票的要素：
时间- 确定列车的剩余票数
区间-
后台开发导论
1接入层服务
通常把网络中直接面向用户连接的部分称为接入层
对外提供一体服务，对内实现负载均衡
DNS
网络接入-DNS
均衡算法:
就近+同运营商接入+轮询
存在问题:
1.域名解析系统的缓存问题(缓存的ip失效将导致出错)
2.公网ip问题
应用场景:
解决服务接入的第一跳
LVS
LvS : Linux Virtual Server , Linux上通用的负载均衡技术
可以将内部的100个IP变成一个IP
LVS-DR
1.Virtual Server via Direct Routing (VS/DR)
通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返E种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但与真实服务器都有一块网卡连在同一物理网段上。
3.Virtual Server via Network Address Translation (VS/NAT)
通过网络地址转换，调度器重写请求报文的目标地址，将请求分派给后端的真实服务器;响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
均衡算法︰
RR、Weight RR、地址hash、最少连接等
优点︰
1.成本低性能高，抗负载能力强
2.业务透明，可应用范围广
3.基于内核网络协议栈，稳定可靠
应用场景∶
解决网络接入的第二跳，一般称为四层负载均衡
问题：
如果连接的服务器出现问题，那么客户端的TCP请求直接失败了
反向代理
负载均衡-反向代理
正向代理:被代理方是客户端
反向代理:被代理方是服务端，服务端隐藏在反向代理后面
反向代理-nginx
nginx可以通过解析http协议包来路由流量 ( http:域名，url , method )
反向代理-手Q接入层SSO
就近接入（相同运营商和相同地域会更快)测速+调度两套系统
连接保持、推送支持
反向代理
信道安全(加密防监听，鉴权防伪装，cookie防重放)
流量优化、数据压缩、智能聚合、精简协议
容灾容错
异常发现和过载保护
负载均衡-七层
均衡算法∶
RR、Weight RR、ip_hash、url_hash
优点︰
1.可针对应用本身来做调度策略
2支持故障剔除
应用场景∶
解决网络接入的第三跳，一般称为七层负载均衡
好处：
因为连接是和代理建立的，当机器出现问题的时候，连接是和代理保持的，可以用反向代理去轮询有没有好的机器
可以更加精细化管理，但是性能没有LVS那么高
总结
通常把网络中直接面向用户连接或访问网络的部分称为接入层
接入层常用技术:DNS、LVS、反向代理
比较大型的在线应用，通常这三种技术都会同时使用
一般DNS和LVS都由公司级别服务提供
GSLB域名管理平台5.1
腾讯云|DNSPOD
负载均衡CLB|Cloud Lo&d Balancer
完整的接入层技术应该包括这三种，日常开发中我们说的接入层一般指反向代理。
2应用服务
网络接入
业务逻辑
数据存储
运维保障
业务需求决定方案
单体架构
小型网站–单机架构
使用到的技术:LAMP
Linux + Apache + Mysql + Php
缓存与读写分离
基于二八定律引入缓存
(高频访问数据提高访问速度）
数据库读多写少->读写分离
（读多写少，分离提速)
动静分离
引入CDN
(将静态资源的访问分流到用户附近的结点)
集群化部罢
通过负载均衡和反向
将请求分散到多个服方命果肝十
服务拆分―业务拆分
项目规模增长，维护难度提高:
任意修改都需要整体发布
任意缺陷都会影响整个系统
解决方案:
将应用按业务模块拆分
分而治之降低复杂度
缩小影响
明确职责
引入消息队列进一步解耦
分布式架构
运营保障
运营保障–微服务框架
组件化、框架化消除重复劳动微服务框架
1.RPC
2.名字服务
3．配置服务
4.日志、监控
5．链路追踪
微服务框架
全链路追踪
什么是全链路追踪
系统监控的三种手段:
Log日志——记录离散事件，包含程序在事件发生时详细信息
Metrics指标——记录可聚合的数据，经过汇总后成为我们关心的指标(QPS、DAU) ——monitor
Tracing链路追踪——记录单个请求的处理流程，其中包括服务调用和处理时长等信息。
Tracing的特点是，它所记录的信息是一个请求范围内的。
微服务时代:
单体应用被拆分为多个微服务，导致服务数量增多、内部调用链复杂化，手Q后端就有600多个模块，涉及到的服务器更是不计其数。
随着服务数量的增多和内部调用链的复杂化，仅凭借日志和指标监控进行问题排查或是性能分析的时候，无异于盲人摸象。
全链路追踪可以帮助我们做到“See the Whole Picture” .
Logging很重要，但存在问题
分布式系统中日志隔离问题:
链路缺乏统一标志:SSO : seq+uin，后端:可能有另一套标识方式
日志染色问题︰各个服务染色不一，日志信息可能在某一环缺失
查问题效率低:查问题时每一个服务方都各自查自己的日志，使用排除法来查问题，效率较低
Metrics必不可少，但不是万能
Monitor和多维监控Habo :
指标数据是我们日常需要关注的，它可以帮助我们发现系统的异常，设置告警并及时处理。
但指标数据是数据的汇总呈现，我们不能依赖其来定位具体问题和优化系统。
Tracing提供了什么
全链路追踪能够帮助开发者直观分析请求链路，快速定位问题和性能瓶颈，逐渐优化服务间依赖，也有助于开发者从更宏观的角度更好地理解整个分布式系统。
cpu问题分析总结
粗看系统负载情况:uptime, vmstat 开发测试环境+线上环境
机器实时的CPU资源消耗详细情况top 开发测试环境+线上环境
分析系统调用: strace 开发测试环境
分析函数的热点:perf，可以输出成火焰图便于直观观察 开发测试环境+线上环境
分析各个线程的资源消耗情况，线程内的函数消耗情况:valgriand 开发测试环境
分析程序各个线程的堆栈执行情况︰pstack & pt-pmp 开发测试环境
内存问题分析总结
1.C++开发的时候必须掌握智能指针
2.熟练使用valgriand分析内存泄漏
3.了解多线程内存库jemalloc/tcmalloc，可以熟悉下jemalloc源代码
4.free的输出结果会解读
5.建议关闭swap
6.熟悉/proc/sys/vm/下的参数，比如控制刷脏页的频率，脏页占有量，
IO问题的分析
几个重要的概念
顺序IO
顺序读写文件，能很好地利用预读，对于机械磁盘也不用做磁头寻道，所以是性能最好的读写模
式，但是一般适用于日志类场景
随机IO
随机读写，机械磁盘性能会非常差，如果是这种场景建议用SSD。当然应用层也会做各种努力尽量会将随机IO改成顺序IO
fsync刷盘
为了数据安全，每次写入完成通过fsync做强制刷盘操作，避免机器突然掉电能情况丢失数据，但是这个操作对吞吐和响应延时有较大的影响，一般会采用一些批量合并fsync的模式做优化
direct io
绕过page cache，直接对设备进行读写，一般性能不如带page cache，适用于在业务层做了cache,比如数据库
aio:异步IO
读写操作异步化，一般也是directio模式，编程会比较复杂，对于大部分应用不要采用，一般也是适用于数据库场景
参考资料
设计一个抢票秒杀系统_luslin1711的博客-CSDN博客
抢票系统之架构设计_lfssst的博客-CSDN博客_抢票系统设计
陈朋 (feishu.cn)
EduFriendChen/snatch-tickets-demo: 解：字节校园镜像技术项目实战活动 —— 【后端】如果有一千万个人抢票怎么办？ (github.com)
中间件概览 | CloudWeGo
cloudwego/hertz-benchmark: Tracking performance changes for Hertz (github.com)