热点侦测流程图
前台系统到后台系统，整个请求是有链路的，一个请求从发起最终到服务端，到数据库层中间需经历多层，过程中存在时间差。特定情况下，会有 1-2 秒延时。利用这一点，当前端请求自导到接受层时，做实时热点侦测，当发现接收层发生变化，可及时通过认证等手段对这个请求做标记，把热点数据记录下来。
之后，把热点数据的信息通知下一个系统，这样就可起到从上游系统发现问题，保护下游的目的。当发现某个请求特别热时，提前对它做拦截。热点数据通过实时发现，日志采集过来，做统计，然后把这个热点数据再导到写数据系统的后端系统 cache 中，这样可保护后端的部分热点系统。
1% 的热点会影响 99% 的用户，这种情况在电商是特别明显的，如某个商品特别热卖，商品请求流量占全网流量很大部分。且上屏容易产生单点，查数据库时将定在同一机器。这样很容易导致某个商品会影响整个网站的所有商品。所以要在数据库做保护，如在本地做 cache、服务层做本地 cache、或者在数据库层单独做一个热点库等。
大流量系统的高可用迭代，需要注意的点有：
热点隔离
先做数据的动静分离
将99%的数据缓存在客户端浏览器
将动态请求的读数据cache在web端
对读数据不做强一致性校验
对写数据进行基于时间的合理分片
实时热点发现
对写请求做限流保护
对写数据进行强一致性校验等
通过多年的高可用架构建设，这里有一些经验值得分享。最大的体会就是需要做稳定性体系化建设，包括建立规范和责任体系；其次就是工具要完善和体系化，以及需要配套的组织保障。
建议在责任体系的建设方面，公司一定每年都要制定高可用指标（KPI）、故障等级也要明晰，影响多少客户都要做描述、责任和荣耀体系也同等重要，这是个长期且苦逼的事。
工具方面，要完善且体系化，做规范，做 KPI，最终要做到工具化，通过工具化把流程、规范能固定。工具要体系化，像全机压测，单机压测等等都可做工具。
一个高可用架构的建设，不是一朝一夕，需要各方面积累和沉淀，一定要注意三方面的处理流程。
关于变更：在变更之前必须制定回滚方案，涉及到对变更内容设置开关，出现问题可快速通过开关关闭新功能；接口变更、数据结构变更、回滚要考虑第三方依赖，在变更之中出现问题，第一时间回滚。
指导原则：将故障清晰描述和暴露出来，获取第一手资料，找到问题反馈源头，解决问题，消除故障同时找到对应系统和业务的直接负责人。
处理流程：问题发现后第一时间上报到“消防群、组建应急处理小组、跨团队合作，通知到对方系统的负责人，P1故障要通知到客服与公关接口人，尽量做到集中办公，问题处理完毕，立即总结和制定改进方案、系统TL负责，改进方案的执行情况。
