摘要：
[toc] 什么是 99.99% 高可用？ 不可用：系统挂掉，很难恢复起来，短时间内都不行，这就不可用 高可用：全年 99.99/99.9/99 % 的时间都能正常提供服务就是高可用 这里有一个比较学术点的解释： 可用性的高低 是使用 不可用时间 占 总时间 的比例来衡量。不可用时间是从故障发生到故 阅读全文
摘要：
[toc] 复制的完整流程 1. slave node 启动，仅仅保存 master node 的信息 但是复制流程没开始，master 信息包括 host 和 ip ， 那么是从哪儿来的？是在配置文件 redis.conf 里面的 slaveof 配置的 2. slave node 定时检查是否需 阅读全文
摘要：
[toc] 主从架构的核心原理 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node， 如果是重新连接：master node 仅仅会复制给 slave 部分缺少的数据; 如果是首次连接：会触发一次 full resynchronization（全量同步 阅读全文
摘要：
[toc] redis 高并发的思路：redis replication 主从架构 读写分离 水平扩容支撑高并发 本章节主要讲解 redis replication 的最最基本的原理，作为铺垫 图解 redis replication 基本原理 在前一章节基本上已经讲过了，如上图差不多。写操作成功之 阅读全文
摘要：
[toc] redis 高并发跟整个系统的高并发之间的关系 搞高并发的话，不可避免的要把底层的缓存搞得很好，这里就是 redis 使用 mysql 来支撑高并发的话，就算做到了，那么也是通过一系列复杂的分库分表方案。订单系统中是有事务要求的，QPS 到几万，就已经比较高了，很难提升上去了 要做一些电 阅读全文
摘要：
[toc] 在企业中，持久化到底是怎么去用得呢？数据备份和各种灾难下的数据恢复，是怎么做得呢？ 企业级的持久化的配置策略 在企业中，RDB 的生成策略，用默认的也差不多，如果有可能改动的地方，可能是如下两个配置： save 60 10000：如果你希望尽可能确保说，RDB 最多丢 1 分钟的数据，那 阅读全文
摘要：
重新安排进度。我喜欢 P.Fagg，一个具有丰富经验的硬件工程师的忠告： “避免小的偏差（Take no small slips） ” 。 也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。 简单、武断地重复一下 Brooks 法则： 向进度落后的项 阅读全文
摘要：
现在，我并不认为软件经理内在的勇气和坚持不如厨师，或者不如其他工程经理。 但为了满足顾客期望的日期而造成的不合理进度安排， 在软件领域中却比其他的任何工程领域要普遍得多。 而且，非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计。 显然我 阅读全文
摘要：
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。 因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。 因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。 另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。 在此之前，项目已经配置了充足的人员， 阅读全文
摘要：
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。 成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。 因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。 阅读全文