前言很多时候我们在工作中总是忙而无效，多数的时间成本都被浪费，定义程序员的产出并不应该是写代码的效率。而是创造的价值和有效性。 当接到开发功能特性的时候，应该问问产品这些问题： 我们为什么要做这个特性，它会给用户或者公司带来怎样的价值？ 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？ 达成这个目的是否有其它手段？是不是一定要开发一个系统？ 上线后，怎么衡量它的有效性？

为什么需要在云时代,随着业务的不断发展和扩大,分布式的系统已经是大部分企业的首选，然而分布式也会带来一个都会遇到的问题，任何一个节点或者组件出现问题都可能会导致整个服务的雪崩。 对于服务雪崩的情况主要有两个解决办法，一个是快速的失败减少系统的复杂，也就是熔断、限流、降级，另一种是快速的扩容，增加服务的负载能力。需要注意的是熔断是被动感知故障的，并且熔断肯定会导致系统的抖动。 熔断生活中就有一些熔断

前言最近在公司参与一个七巧板的团队游戏，游戏规则其实很简单，但是前提是大家能有效的沟通并达成一致。最终以未能达成目标而结束，整个游戏让我意识到沟通是保证有效工作的前提条件，也是非常重要的一项工作技能，因此自己总结归纳了一些自己对于沟通以及如何沟通的感受和心得。 什么是沟通比较官方的说法:沟通是指运用语言、文字或一些特定的非语言行为（面部表情、肢体动作等），把自己的想法、要求、信息等内容传递给对方。

减少对学习的排斥峰值和终值。人们对一切人、事、物的感受，由峰值和终值两个因素决定。峰值是指这段体验中的最高峰，包括正向和负向。终值是指这段体验结束时给你的感觉。在学习中应该避免负向峰值的出现，艰难和轻松的任务穿插着去完成是保持愉悦和高效的重要方法，轻松的任务可以是休息，散步，听音乐，或者睡一觉。 避免负向峰值的几个方法： 在制定计划的时候，量力而行，不要制定完不成的计划。 一天内的计划种类不要太

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

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

前言记录一下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 性能下降。 譬如这个