Logstash 聚合插件 aggregate filter 的使用心得
在ELK常规的使用模式下，我们收集Nginx访问日志是按照单行进行的。这样比如说有10个用户请求，对应在ElasticSearch中就是10条记录（也称为10个document）。下面将分别描述此种收集方法的优缺点。
首先，这样的收集方式非常利于按照指定字段去搜索，并根据匹配的记录去查看其它字段的信息。比如统计客户端IP为 127.0.0.1 的请求有多少，使用IPhone 手机的请求有多少。当出现 499 、502 状态码时，看看这些请求的URL是什么，然后快速定位问题。这些方法都是非常非常实用而且好用的。
其次，除了上面的这些需求之外，我们还想要制作统计图，比如统计按时间范围统计总请求数，4xx 数量，5xx数量，响应时间超过 500ms的请求数，输出的字节数量，平均响应时间。特别是最后2项，时间范围跨度越长，数据量越大，计算时间就越长。据我们实际使用中的数据量，单个索引，每天 3亿的文档数量，对应就有120G左右的数据，在单个dashboard中同时展示上面的几种图标，如果时间跨度超过1小时，页面加载时间就会超过 2s 。而kibana又提供了自动刷新功能，这样如果有多个人同时使用 elasticsearch就会咔咔的慢。
全局唯一 ID 如何生成？
ID 生成，提到这个词可能最快想到的就是 MySQL 数据库 insert 时的自增ID。当业务访问量剧增，单表的 insert 性能遇到瓶颈时，我们就必须使用分库、分表机制来分担这些负载到单个MySQL表上，但是我们都知道MySQL表中的主键自增是基于单表的，如果2个表中有2个自增字段，那他们默认都是从1开始自增，每次增加步长为1，那么这在有些业务场景下就不满足需求了。比如订单系统，必须要保证订单ID是全局唯一的，也就是所有订单库、表中的ID不能相同，不能用2个相同的订单ID代表不同的订单信息。
那么，我们有没有办法来解决这个问题，那肯定是有的，我想所有的方案不外乎这3种，第一，直接使用MySQL来解决，第二，依赖其他中间件生成唯一 ID（比如 redis），第三，业务中使用算法实现唯一ID。我们接下来分别来阐述这3种不同的解决方案，及其对应的优缺点。
Redis Replication 实现原理
对于 Master/Slave 模式，在我们常用的Mysql中你一定有或多或少的了解，应该知道它的一些价值，比如灾备、读写分离。就灾备一项就足以使我们必须使用它，因为一旦服务器软硬件故障，可能造成数据永不可恢复。你可能会说，可以提前做好数据文件备份，但是要远比修改一个 IP 更加复杂与时间开销更大。在Master/Slave 模式下还可以结合LVS/Keepalived 实现故障自动转移，使其具体业务方无感知。
在 Redis 2.8 版本之前，Master/Slave 之前只支持全量同步（full resync），从 2.8版本开始支持了部分重同步（partial resynchronization），使得在短暂的网络中断恢复后，不需要进行全量数据同步，而是只同步最近新增的数据即可。那么如何理解这个“短暂”，其实是取决于配置参数与实际场景，下面将带大家一起抽丝剥茧，找出真相。