系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
千万流量：大致就是每秒钟几百个请求
四种微服务粒度
统一一个服务层一个子业务一个服务（时间最多）一个库一个服务一个接口一个服务总的方法论：集群冗余 + 故障的自动转移
细节：
“端” 到 “反向代理” （反向代理冗余，keepalived + vip）“反向代理” 到 “站点应用” （站点层冗余，nginx和web-server之间的存活性探测与故障自动转移）“站点应用” 到 “微服务“（服务层冗余，server连接池来实现故障自动转移）”微服务“ 到 ”缓存“（客户端对缓存双读双写，或缓存集群主从同步，sentinel保活与故障自动转移）”微服务“ 到 ”读库“（微服务到读库的连接池来实现）”微服务“ 到 “写库”（写库的冗余，写库keepalived + vip）方法论：垂直扩展，水平扩展（理论无限性能）
细节：
反向代理层（DNS轮询）站点应用层（nginx配置）微服务层（服务连接池）数据层（数据切分）任何脱离业务的架构都是耍流氓
依据“业务模式”设计库表结构依据“访问模式”设计索引结构方法论上：冗余 + 故障自动转移
数据库的冗余将引发一致性问题
主从数据冗余，主从不一致
忽略强制读主借助缓存，选择性读主主主数据冗余，主主不一致
数据库不同的初始值，相同的增长步长应用层生成不冲突的ID仅让一个主库提供服务扩展性，解决什么问题
底层表结构的变更水平扩展，分库个数变化底层存储介质的变化方案一，停服扩展（离线，非高可用）
挂公告，暂停服务离线迁移数据恢复服务方案二，pt-online-schema-change（平滑）
方案三，追日志方案（平滑）
升级服务，记录日志离线迁移数据追日志，补充增量校验数据迁移流量方案四，双写方案
服务升级，“数据修改”双写迁移数据小工具，进行数据迁移数据校验小工具，进行数据校验切流量到新库方案五，成倍秒级扩容
互联网大数据量，高吞吐量，高可用微服务架构数据库实现秒级平滑扩容的三个步骤：
修改配置（双虚ip，微服务路由）reload配置，实例倍增完成删除冗余数据等收尾工作，数据量减半完成尽量把：
长度较短访问频度较高经常一起访问的属性放在主表里
优点
节省内网带宽时延更低不足：一致性难以保证
保证一致性的方法
单节点通知其他节点MQ通知其他节点放弃实时一致性，定期从后端同步数据什么场景下适用
只读数据并发极高，透传后端压力极大允许一定程度上的数据不一致它是互联网缓存的最佳实践
读实践：先读缓存，若命中则返回，若未命中则读库，并设置缓存写实践：使用淘汰缓存而不是修改缓存，先操作数据库再淘汰缓存优化思路：如果有旧数据进入缓存，应该及时把这个数据淘汰掉
方法
二次淘汰法（异步二次淘汰，服务二次淘汰）设置超时时间，有机会修正什么时候选择redis
复杂的数据结构持久化天然高可用存储内容比较大什么时候适合使用mc
纯kv数据
为什么mc在纯kv更快
预分配内存池redis的VM机制更慢redis数据结构复杂，CPU要做复杂计算多线程可利用多核其它
redis的源码可读性很好二者都需要自己做手动的水平切分千万流量篇总结：
【成为架构师3-1】服务化：微服务架构，究竟解决什么问题 【成为架构师3-2】服务化：微服务的粒度，究竟要细到什么程度 【成为架构师3-3】服务化：必须保证高可用 【成为架构师3-4】服务化：必须支持高并发 【成为架构师3-5】服务化：必须搞定负载均衡 【成为架构师3-6】服务化：连接池，微服务的基础组件 【成为架构师3-7】服务化：连接池，高可用、可扩展、负载均衡都离不开它
【成为架构师3-8】数据库：如何提升数据库的读性能 【成为架构师3-9】数据库：垂直拆分与高可用 【成为架构师3-10】数据库：主从一致性和主主一致性 【成为架构师3-11】数据库：扩展性要如何解决 【成为架构师3-12】数据库：扩展性，平滑扩展如何实现 【成为架构师3-13】数据库：水平切分，数据库秒级扩容
【成为架构师3-14】缓存：进程内缓存该怎么玩 【成为架构师3-15】缓存：常见误用与实践 【成为架构师3-16】缓存：互联网缓存的最佳实践Cache Aside Pattern 【成为架构师3-17】缓存：数据一致性优化二次淘汰法 【成为架构师3-18】缓存：并发更新造成token相互失效的问题 【成为架构师3-19】缓存：究竟是选择redis还是memcache
下一篇更精彩：持续更新中…
