如何复盘系统在线上出现异常是不可避免的，但是可以降低问题发生的概率，减少问题导致的损失。所以在出现问题后及时有效复盘可以帮助团队更好的避免故障。 复盘包括事实、分析、订责、改进四个部分。 事实：首先事实是复盘的基础，如果事实都没讲清楚就开始分析改进是没有任何意义的。 分析：保证没有任何遗漏的问题，深入分析问题的根因。 定责：有明确的定责标准，不要胡乱甩锅。 改进：定制完整的可落地的改进方案。

停机部署停机部署应该是一个已经基本被历史淘汰的部署方式，它非常简单粗暴，直接把现有服务直接停机，然后部署新的版本，停机部署现在基本只会用在一些新老版本强制切换且互不兼容的情况下。 它的优势在于不会存在新老版本兼容的问题，缺点是显而易见的，停机的时候所有的用户都将处于无法使用的状态。 蓝绿部署蓝绿部署也比较好理解。会在生成环境同时部署两个一模一样的集群，一个是老的服务，一个即将发布的新服务，也就是常

前言记录一下ApplePay 非订阅商品的服务端单据验证流程，以及在其中遇到的问题。总的来说苹果的这套单据验证流程还是挺反人类的。 苹果应用内支付流程 iap(in app purchase)这个是我正在使用的苹果支付大致支付成功的流程图。 首先获取商品列表，这里面包含苹果的 product_id，这个非常重要。 之后客户端直接唤醒支付并支付，这里并没有提前找商户服务创建订单，主要是为了减少流程

什么是数据倾斜Redis 数据倾斜指的是在 Redis 集群中，某些节点的负载过高，而其他节点负载较轻的情况。负载包括数据量的负载和访问量的负载，譬如实例上的数据分布不均衡，某个实例上的数据特别多。在或者某个实例上的数据是热点数据，被访问得非常频繁。这些都是数据倾斜的问题，严重会影响到 Redis 性能和稳定性。 数据量倾斜原因和解决方法Hash TagHash Tag 是 Redis 中的一个客

哨兵集群哨兵机制是在 redis 2.8 引入的，核心功能就是当主库发生故障自动故障转移，它本质其实就是一个 redis 进程，下图就是一个基本的哨兵集群。 故障转移的基本流程是， 监控-选主-通知 哨兵在运行的时候，会周期性(一秒)的给所有的节点发送 PING 命令来检测节点是否处于正常状态。如果节点没有在配置时间内响应那么就会被标示为下线状态。如果是主库被下线，哨兵会按照一定的规则在从库中选取

切片集群假设需要有30G的数据需要存入到 redis, 所有数据放一个实例中虽然是可行的， 但是如果把蛋都放在一个篮子里务必就会产生很多风险和副作用。譬如： 当数据增多时只能纵向扩展，且到了一定阶段还需要考虑到硬件成本问题。 如果是使用 RDB 进行持久化时，Redis 会 fork 父进程的页表给子进程，页表的数量上，数据越大，页表越多，复制就越花时间，导致 redis 性能下降。 譬如这个

设计原则 设计原则 创建型 单例模式 工厂模式 生成器模式 原型模式 结构型 代理模式 桥接模式 装饰器模式 适配器模式 组合模式 外观模式 享元模式 行为型 观察者模式 模版模式 策略者模式 责任链模式 状态模式 迭代器模式 访问者模式 命令模式 备忘录模式 解释器模式 中介者模式

前言设计原则是指导代码设计的一些经验总结。设计原则这块儿的知识有一个特点，那就是这些原则听起来都比较抽象，定义描述都比较模糊，不同的人会有不同的解读。它们共同的目标都是高内聚低耦合，高内聚用来指导类的设计，低耦合用来指导类之间的依赖关系，高内聚有助于松耦合，松耦合需要高内聚的支持。 SRP 单一职责原则原则定义：一个类或者模块只负责完成一个职责（或者功能）。类和模块可以有两种理解，一种理解是把模块

中介模式(Mediator Pattern)中介模式定义了一个单独的中介对象，来封装一组对象之间的交互。将这组对象之间的交互委派给与中介对象交互，来避免对象之间的直接交互。 结构图： 角色： 抽象中介者(Mediator)：接口声明了与组件交流的方法，但通常仅包括一个通知方法。 具体中介者(Concrete Mediator)：封装了多种组件间的关系。 具体中介者通常会保存所有组件的引用并对其

解释器模式(Interpreter Pattern)任何可以承载信息的载体，都可以称之为语言，语言如果想被理解，需要按照特定的语法去编排生成，解释器就是根据语法规则去解释语言。 结构图： 角色： 抽象表达式(Abstract Expression)：声明解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。 终结符表达式(Terminal Expression)：实现与语