Redis Cluster 学习笔记
- 启动节点
- 通过命令配置集群（a. 加入节点 b. 分派slot c. 添加slave)
- 接受命令处理
- 根据key，转发到不同的节点
- 特殊的标记{…}，可以分派key到相同的节点，{} 不能在key的结尾。如果有{…} ,hash算法则使用{与}中间的字符串来计算，所以一定要在{}中间有字符，不然所有的key将会分配到一个节点。
- 命令中有多个key，如果这些key不在相同的slot（即使在相同的节点也不行），则返回错误（getNodeByQuery）
- 根据key获取节点（getNodeByQuery）
搭建调用链路监控系统
现在微服务非常盛行的年代，在公司内，有各种各样的微服务相关的实践。今天我们不展开微服务具体是什么，只需要了解在一个互联网服务系统内部可能是由N多个子服务组成，每个子服务独立开发、部署、维护，通过API/RPC与其他服务通信，而不是直接共同操作相同的数据库、表来实现数据交互。在这样的架构之下，服务间的调用链路关系可能是这样的：a -> b -> d -> e
a -> c -> d -> b -> f
以这个单向的调用为例，实际场景可能是更加复杂的网状形式。比如 a 是对用户提供服务，其内部的2个功能分别会有2个不同的调用链路。这时如果 a 检测到一个错误发生，那么怎么确定是 a 自身异常导致的，还是由于上游服务 b/d/e 异常导致的。如果不能很好的、快速的定位最根本的异常产生在哪里，那么势必会影响故障恢复时间，进而影响到服务的可用性。
搭建ELK日志监控平台那些事
ELK 是 elasticsearch / logstash / kibana 这三个英文单词的缩写，也即表明，这个技术栈中包含这三个组件，都是一家公司出品（www.elastic.co）。
kibana 负责展示，数据从elasticsearch中获取
logstash 负责收集并解析日志数据，然后输出指定格式到elasticsearch
elasticsearch 负责保存数据，并提供检索功能。
这些组件可以在具体场景中按需组合使用，也可以单独使用。其中最有名气的当属 elasticsearch，是基于 Lucene 实现的高可用，高性能的搜索服务。现在，众多中大型企业级搜索就是使用的它，值得我们去好好学习一下。
Redis Sentinel 高可用原理
现在 B/S C/S 架构的软件系统设计时，我们通常需要把服务端设计为高可用系统，比如 3个9（99.9%），4个9（99.99%），5个9（99.999%）。这是由于随着用户请求量的增加，服务端系统需要处理的事务会增加，进而可能会导致服务端系统无法快速、正确响应用户请求，使得用户体验变得非常糟糕。最终可能会使得用户流失，对广告、会员等这部分收入产生严重影响。另外，Redis作为基础组件，一旦出现故障，可能会使得好多业务出现异常。因此高可用是非常有必要的，也是一个软件开发者应该具备的基本能力之一。
Redis Sentinel 通信流程
准备工作：
1. 配置 master slave 、修改sentinel 配置，如下：Redis.conf monitor <Master1> <host> <port> <quorum> monitor <Master2> <host> <port> <quorum>2. 启动 master / slave 节点，然后再启动 sentinel 节点
Redis RDB 文件存储实现
redis通过把内存数据保存为rdb文件来实现快照，是整个redis内核中不可缺少的一部分，为实现服务高可用提供了强有力的支撑。有以下2点作用：1. 持久化 （比 aof 恢复速度更快，也占用更小的磁盘空间，因此作为默认的持久化方式）
2. 主从同步 （开启主从后，需要首先把master上的历史数据同步到slave，这时slave就会拉取master的rdb文件，然后解析加载rdb文件到内存）
hubot + slack 结合
在上一篇文章中介绍过 hubot 以及其如何安装，如何使用默认方式运行。这篇文章将介绍与 slack 结合使用，slack 是一个第三方托管的开发聊天室系统，类似于github的模式，真是看上去非常强大，不过我本人之前也没有太多接触这个东西，可以自行搜索了解。在之前已经介绍过，现在已经有人实现了针对 slack 的 hubot 适配器（Adapter） ，因此可以使其组合使用 ，下面将介绍具体步骤，