08 2020 档案
摘要：总结 （1）互联网缓存最佳实践：Cache Aside Pattern （2）读实践：先缓存，命中返回，未命中读数据库，再设置缓存 （3）写实践：淘汰缓存而不是修改缓存，先操作数据库，而不是先淘汰缓存
阅读全文
摘要：总结，进程内缓存 （1）服务与服务之间不要通过缓存传递数据 （2）如果缓存挂掉，可能导致雪崩，此时要做高可用缓存，或者水平切分 （2）调用方不宜再单独使用缓存存储服务底层的数据，容易出现数据不一致，以及反向依赖 （2）不同服务，缓存实例要做垂直拆分，不宜共用缓存
阅读全文
摘要：总结，进程内缓存 优点： （1）节省内网带宽 （2）时延更低 不足：一致性难以保证 什么场景适用？ （1）只读数据 （2）并发极高，透传后端压力极大 （3）允许一定程序上数据不一致 保证一致性的方法？ （1）单节点通知其他节点 （2）MQ解耦，通知其他节点 （3）放弃实时一致性，定期从后端更新数据
阅读全文
摘要：总结，数据库水平切分，秒级成倍扩容 互联网大数据量，高吞吐量，高可用微服务分层架构 数据库实现秒级平滑扩容的三个步骤为： （1）修改配置（双虚ip，微服务数据库路由）； （2）reload配置，实例增倍完成； （3）删除冗余数据等收尾工作，数据量减半完成；
阅读全文
摘要：总结，追日志方案 VS 双写方案 追日志方案： 追日志方案： （1）服务升级，记录“数据修改”的日志； （1）服务升级，“数据修改”双写； （2）迁移数据小工具，进行数据迁移； （2）迁移数据小工具，进行数据迁移； （3）追日志小工具，追平数据库差异； （3）追日志小工具，追平数据库差异； （4）数
阅读全文
摘要：总结 扩展性，解决什么问题? （1）底层表结构变更 （2）水平扩展，分库个数变化 （3）底层存储介质变化 方案一，停服扩展（离线，非高可用） （1）挂公告，暂停服务 （2）离线迁移数据 （3）恢复服务 方案二，pt-online-schema-change（平滑） 方案三，追日志方案（平滑） （1）
阅读全文
摘要：总结 主从数据冗余，主从不一致： （1）忽略 （2）强制读主 （3）借助缓存，选择性读主 主主数据冗余，主主不一致： （1）数据库不同初始值，相同增长步长 （2）应用层生成不同冲突ID （3）一个主库提供服务 数据库工程架构设计，必须考虑什么： （1）读性能提升 （2）高可用 （3）一致性保障 （4
阅读全文
摘要：总结 垂直拆分？尽量把： （1）长度较短 （2）访问频率较高 （3）经常一起访问 的属性放在主表里； 原因：数据库缓冲池，逻辑上，以row为单位缓冲数据。 举个例子，假设缓冲池1G Case1，未拆分： user表，1行记录为1k，只能缓存100w行数据 Case2，垂直拆分： user_base表
阅读全文
摘要：总结 数据库要设计什么： （1）依据“业务模式”设计表结构 （2）依据“访问模式”设计索引结构 读性能提升，常见方法与实践： （1）增加索引，不同实例不同索引 缺点：① 写性能降低 ②索引占用内存大，buffer命中率降低，读性能降低 实例：用户中心功能实施一主两从，读写分离架构。 其中主库只为线上
阅读全文
摘要：总结：连接池，高可用+可扩展+负载均衡 细节： （1）高可用，故障自动转移 （2）扩展性，服务发现：自动载入新服务节点配置（1 监控配置文件，并重新载入，2 配置中心回调，并重新载入）+动态连接池 （3）负载均衡：轮询，随机，静态权重，动态权重
阅读全文
摘要：总结：连接池 1 在有连接池之前，怎么访问下游？ （1）建立连接 （2）通过连接，收发请求 （3）关闭连接 2 提前建立连接池之后，怎么访问下游？ （1）拿一个连接 （2）通过连接，收发请求 （3）放回连接 细节： （1）为什么要连接池（频繁的建立连接与销毁连接，在吞吐量提升到一定级别的时候，会成为
阅读全文
摘要：总结：负载均衡，是分布式系统架构设计必须考虑的因素 含义：将请求或数据，均匀的分摊到多个操作单元上执行 方法论： （1）同构，重点在于“均匀” （2）异构，重点在于“负载与能力匹配” 细节： （1）反向代理层、站点应用层、微服务层、数据层如何实施负载均衡 （2）连接池很重要，高可用/扩展性/负载均衡
阅读全文
摘要：总结：高并发，是分布式系统架构设计必须考虑的因素 含义：通过设计一些方案，保证系统能够同时并行的处理很多用户的用户请求 指标：（1）响应时间（Response Time） （2）吞吐量（Throughput） （3）每秒查询率QPS（Query Per Second） （4）并发用户数 方法论： 1
阅读全文
摘要：总结：高可用，是分布式系统架构设计必须考虑的因素 含义：通过减少系统不能提供服务的时间 方法论：集群冗余+故障自动转移 细节： （1）“端”到“反向代理” ##反向代理集群冗余+故障自动转移（keepalived+virtual IP） （2）“反向代理”到“站点应用” ##站点层冗余+反向代理配置
阅读全文
摘要：总结，微服务粒度 （1）统一服务层 （2）一个子业务一个服务 （3）一个库一个服务 （4）一个接口一个服务 互联网最佳实践：一个子业务一个服务
阅读全文
摘要：总结，服务化有什么好处？ （1）复用性，消除代码拷贝 （2）专注性，防止复杂性扩散 （3）解耦合，消除公共耦合 （4）高质量，SQL稳定性有保障 （5）易扩展，消除数据库解耦合 （6）高效率，调用方研发效率提升
阅读全文
摘要：单体ALL in one 架构，遇到什么问题，架构如何演进？ （1）技术不炫技，以解决业务问题为导向； （2）系统改造尽可能小的架构方案； （3）以最快的速度，提升系统的性能，解决遇到的问题； 问题一：如何突破单机资源限制，提升性能？ 架构演进：伪分布式，提升性能 三大分离 （1）动静分离 （2）读
阅读全文
摘要：总结： （1）早期，对架构影响最小，最快提升性能的优化方法：三大分离； （2）动静分离，是指“静态页面与动态页面，分开不同的系统访问”的架构设计方法； （3）读写分离，用数据库分组，快速提升数据库读性能； （4）水平切分，用数据库分片，提升数据库存储容量（往往涉及系统改造）； （5）前台后台分离，系
阅读全文
摘要：总结： （1）早期，对架构影响最小，最快提升性能的优化方法：三大分离； （2）动静分离，是指“静态页面与动态页面，分开不同的系统访问”的架构设计方法； （3）“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术； （4）总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态
阅读全文
摘要：总结： （1）web-server如何实施负载均衡？http短连接，可以利用反向代理。 （2）tcp-server如何快速实施？单体架构，但无法保证高可用。 （3）tcp-server如何快速实施负载均衡+高可用？客户端内置集群，但无法保证扩展性。 （4）tcp-server如何保证负载均衡+扩展性
阅读全文
摘要：CDN如何实现就近访问？ （1）CDN的核心是就近访问，降低网络拥塞，提高用户访问速度； （2）CDN适合静态资源（js，css，jpg，flash，静态html等）加速； （3）CDN的核心是“智能DNS”； （4）CDN由智能DNS，源，镜像构成； （5）常更新的静态资源，建议加上版本号，防止数
阅读全文
摘要：session一致性，该怎么玩？ 总结：如何保证session一致性？ （1）session同步法：多台web-server相互同步数据； （2）客户端存储法：一个用户只存储自己的数据； （3）反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server
阅读全文
摘要：DNS轮询,是过时的技术么？ 总结：DNS轮询，并不是过时的技术 （1）单体架构，要解决性能扩展问题，早期，使用DNS轮询架构； （2）现在，可以使用nginx反向代理架构； （3）反向代理，不高可用，需要进一步升级为高可用反向代理架构； （4）高可用反向代理，扩充性能，可以使用多级（LVS&F5）
阅读全文
