稳定性三十六计-历史记录

引子

半夜三点，睡梦中被一阵没人接听誓不罢休的电话铃吵醒。睡眼惺忪的接听了电话，电话那头传来了不用听清任何人类语言就能感觉的焦急。让我赶快打开电脑，说服务整个不工做了！

打开监控看到线程池被打满。本着“先恢复现场再排查缘由”的基本原则，重启并扩容了一倍的服务器。服务又正常了。完美的作到了“三分钟定位，十分钟解决”。可是现场不在了，怎么排查根因呢？答案是：历史记录。

 

为何要作历史记录

历史记录是大数据的最重要数据源。经过历史记录能够进行事件追溯、将来预判和推荐。举个例子：

静儿在网上搜索了“稳定性三十六计”这个词，找到本身想要的内容了。而后去作别的事情，再打开浏览器的时候，发现旁边的小弹出框里推荐我《稳定性宝典》这本书。

这个推荐效果不少种算法都能实现，好比最近比较火的“协同过滤推荐算法(Collaborative Filtering Recommendation)”。啥是协同过滤推荐算法呢？协同过滤推荐算法简而言之，就是找到相同兴趣的群体，将这个群体中感兴趣的其余信息推荐给用户。

实施的时候能够先创建一个大表，X轴是全部的推荐内容，Y轴是全部的用户。

而后咱们将每一个用户感兴趣的XY交叉点都标出来。如图能够看到对“稳定性三十六计”感兴趣的对“稳定性宝典”感兴趣的几率也很高。

历史记录对于稳定性，也能够将其余同类系统做为用户，将他们的问题做为推荐项进行协同过滤分析，找到自身的可优化点。系统出了问题须要分析缘由时，事件追溯更是必不可少。

 

怎么作历史记录

日志

最经常使用的事件维度记录是日志。有存于本地磁盘和集中式日志两种。

本地磁盘日志就是将日志在程序中控制直接写入本地磁盘。

集中式日志的架构大同小异，基本结构以下：

• 采集器负责采集数据，并发送给收集器。
• 收集器负责收集采集器发送过来的数据，并定时写入集群。
• 存储中心负责对数据分类、排序、去重，把同类型的数据合并。
• 分析和可视化平台负责数据的展现。

如下是经常使用的数据收集系统的比较

 

产品	公司	优点	劣势
Flume NG	Cloundera	1.支持故障转移和负载均衡 2.容易水平扩展 3.社区活跃、文档丰富 4.依赖第三方类库少 5.经过事务保证数据一致性 6.支持多种存储	1.须要本身实现客户端代码 2.对数据的过滤能力差
Scribe	Facebook	1.具备很高的容错性 2.支持水平扩展	1.依赖zookeeper或Hash等工具 2.须要本身实现客户端代码 3.社区活跃度低、文档少 3.依赖第三方库多 4.部署复杂 5.存储系统类型少 6.数据过滤解析能力差 7.官方已经中止更新和维护
Chukwa	Apache	1.高可靠 2.易扩展 3.社区活跃度较高 4.文档资料丰富	1.依赖hadoop
ELK	Elasic.co	1.提供完整的解决方案 2.支持集群部署和水平扩展 3.社区活跃度高、文档丰富 4.部署简单	1.占用资源比较高

ELK不是一款软件，而是Elasticsearch、Logstash和Kibana首字母的缩写。这三者是开源软件，一般配合一块儿使用。并且前后归于Elasic.co公司的名下，因此简称ELK Stack。根据Google Trend的信息显示，ELK已经成为目前最流行的集中式日志解决方案。

 

Nosql

除了日志，任何有价值的历史信息都是应该存储起来作分析的。这时候存储就是关键。由于数据量大，对强一致性没有苛刻的要求。因此从成本上传统的关系型数据库不是首选。通常选择Nosql数据库。Nosql数据库主要有四类：

1.key-value数据库

 

项目	说明
典型应用场景	内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统
数据模型	Key指向Value的键值对，一般用hash table实现
强项	查找速度快
弱项	数据无结构，一般被当作字符串或者二进制数据
例子	Redis、Memcached

2.列式数据库

项目	说明
典型应用场景	分布式的文件系统
数据模型	以列簇式存储，将统一列数据存在一块儿
强项	查找速度快，可扩展性强，更容易进行分布式扩展
弱项	功能相对局限
例子	Cassandra、HBase

3.文档型数据库

项目	说明
典型应用场景	Web应用，Value是结构化的，容易被解析
数据模型	KeyValue的键值对，Value为结构化数据
强项	数据结构要求不严格，表结构可变、不须要预先定义表结构
弱项	查询性能不高，缺少统一的查询语法
例子	CouchDB、MongoDB、Elasticsearch

4.图结构数据库

项目	说明
典型应用场景	社交网络，推荐系统等。专一于构建关系图谱
数据模型	图结构
强项	利用图结构相关算法，好比最短路径寻址，N读关系查找等
弱项	须要再次计算出所需信息，不容易作分布式集群方案
例子	Neo4j、InfoGrid、Infinite Graph

 

时序数据库

时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签的数据。带时间标签的数据也称为时间序列数据。

基于时间序列数据的特色，关系型数据库没法知足对时间序列数据的有效存储与处理，所以迫切须要一种专门针对时间序列数据来作优化的数据库系统，即时间序列数据库。

目前行业内比较流行的开源时序数据库产品对好比下：

 

	InfluxData	Prometheus	Graphite	OpenTSDB
数据模型	labels	labels	dot-separated	label
按时间分段管理数据	✔️	✔️	✔️	手动
分布式	✔️商业版	单机	单机	✔️
聚合分析	弱	弱	弱	弱
权限管理	✔️商业版	×	×	×
接口	类SQL	REST	REST	REST
社区生态	+++	++	++	++
时间序列分析	无	无	无	无
抽取日志指标	×	×	×	×
Rollup	✔️	×	✔️	×

 

总结

Talk is cheap, show me the data! 

 

推荐阅读

• 盖洛普Q12在团队中的应用

• 演讲稿：新人培养之道

• 自动化管理之新人培养

• 和真正的程序员在一块儿是怎样的体验

• 从技术渣到被要求改行到硅谷程序媛

• 《程序员修炼之道》解读1

• 到底多大才算高并发？

• 年纪大了，是否该往管理方向转型？

• 《跃迁-成为高手的技术》感悟

 

关于做者

一线开发十二年，有日本东京和美国硅谷研发经验。有百余项技术发明专利，目前任美团点评技术专家。有本身的技术公众号「编程一辈子」。若是您在阅读本书时有什么疑问或者发现本书的错误，欢迎在公众号里给我留言。