标签：异构 缓存 架构 核心技术 系统 拆分 亿级 聚合 数据
《亿级流量网站架构核心技术》
墨菲定律
- 任何事情都美哦有表面看起来那么简单
- 所有的事都会比你预计的时间长
- 可能出错的事总会出错
- 如果你担心某种情况发生，那么它就更有可能发生。
康威定律
- 系统架构事公司组织架构的反映
- 应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本
- 如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整
- 在合适时机进行系统拆分，不要一开始就把系统/服务拆得非常细，虽然闭环，但是每个人维护的系统多，维护成本高。
高并发原则
- 无状态：应用无状态，配置文件有状态，应用比较容易做水平扩展。
- 拆分：是单块系统还是按功能模块拆分系统根据环境进行权衡
系统维度：系统功能/业务拆分
功能维度：功能拆分
读写维度：读写比例特征进行拆分
大量读的情况，考虑使用缓存提升性能
大量写的情况，考虑使用分库分表
聚合读的情况，数据异构拆分系统，将分散在多处的数据聚合到一处存储
AOP维度：根据访问特征，按照AOP进行拆分。CDN、页面渲染系统都属于AOP。
模块维度：按照基础或者代码维护特征进行拆分。 - 服务化：进程内服务 -> 单机远程服务 -> 集群手动注册服务 -> 自动注册和发现服务 -> 服务的分组/隔离/路由 -> 服务治理如限流/黑白名单
- 消息队列：服务解耦（一对多消费），异步处理，流量削峰/缓冲等。
(1) 为流量缓冲
牺牲强一致性，而保证最终一致性
(2) 数据校对
保证数据一致性和完整性
Worker扫描原始表，对业务数据进行校对，有问题的要进行补偿 - 数据异构
(1) 数据异构
查询某个用户的订单，则需要聚合多个表才能返回，订单表读性能很差，对订单表进行异构
异构一套订单表，按照用户ID进行分库分表，考虑对历史数据的归档
其它方法，异步加载，合并请求
(2) 数据闭环- 数据异构：通过MQ机制接收数据变更，原子化存储到合适的存储引擎，如Redis或持久化KV存储
- 数据聚合：
数据异构 —— 把数据从多个数据源拿过来
数据聚合 —— 数据聚合的目的是把这些数据做个聚合 - 前端展示：前端通过一次或少量几次调用拿到所需要的数据
- 缓存银弹
| 流程节点 | 缓存技术 |
|---|---|
| 客户端 | 使用浏览器缓存 |
| 客户端应用缓存 | |
| 客户端网络 | 代理服务器开启缓存 |
| 广域网 | 使用代理服务器（含CDN） |
| 使用镜像服务器 | |
| 使用P2P技术 | |
| 源站与源站网络 | 使用接入层提供的缓存机制 |
| 使用应用层提供的缓存机制 | |
| 使用分布式缓存 | |
| 静态化、伪静态化 | |
| 使用服务器操作系统提供的缓存 |
标签：异构,缓存,架构,核心技术,系统,拆分,亿级,聚合,数据 来源： https://www.cnblogs.com/richardcuick/p/16080097.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。