我所读过的最好的一篇分布式技术文章学习笔记:The Log( 八 ) _log

2.11 Log 合并
显然，用log记录全时全量的状态变更信息。不太可能。
Kafka使用了log合并或者log垃圾回收技术：
1) 对于事件数据，kafka仅仅保留一个时间窗体(可在时间上配置为几天，或者按空间来配置)
2) 对于keyed ，kafka採用压缩技术。
此类log 。能够用来在另外的系统中通过重放技术来重建源系统的状态。
假设保持全时全量的logs，随着时间增长，数据将会变得越来越大，重放的过程也会越来越长。
Kafka不是简单地丢弃老的日志信息，而是採用合并的方式。丢弃废弃的记录，比方。某个消息的主键近期被更新了。
2.12 系统构建 2.12.1 分布式系统
Log，在分布式数据库的数据流系统和数据集成中所扮演的角色是一致的：
你能够将整个机构中的应用系统和数据流，看作是一个单独的分布式数据库。
将面向查询的独立系统，比方Redis , SOLR , Hive等等，看作是一种特别的、数据之上的索引。
将Storm、Samza等流处理系统，看做一种精心设计过的触发器或者物化视图机制。
各式各样的数据系统。爆发性的出现。事实上。这样的复杂性早已存在。
在关系型数据库的辉煌时期() 。某个公司或者机构光关系型数据库就有非常多种。
显然，不可能将全部的东西都丢进一个集群中，期望其解决全部的问题。
所以，怎样构建一个好的系统，可能会像以下这样：
构建一个分布式系统。每一个组件都是一些非常小的集群，每一个集群不一定能完整提供安全性、性能隔离、或者良好的扩展性。可是，每一个问题都能得到(专业地)解决。
Jay哥觉得，之所以各式各样的系统爆发性地出现。就是由于要构建一个强大的分布式系统十分困难。
而假设将用例限制到一些简单的，比方查询这样的场景下，每一个系统都有足够的能力去解决这个问题，可是要把这些系统整合起来，非常难。
Jay哥觉得在未来构建系统这事儿有三种可能：
1) 保持现状。这样的情况下。数据集成依然是最头大的问题。所以一个外部的log系统就非常重要(kafka！)
2) 出现一个强大的(假设辉煌时期的关系型数据库)能解决全部问题的系统，这似乎有点不可能发生(提它干嘛？) 。
3) 新生代的系统大部分都开源，这揭示了第三种可能：数据基础设施可被离散为一组服务、以及面向应用的系统API,各类服务各司其事，每一个都不完整，却能专业滴解决专门的问题。事实上通过现存的java技术栈就能看出端倪：
从某种角度来看，构建这样的分布式系统，就像某个版本号的乐高积木一样。这显然跟更关心API的终端用户没有太大关系，可是这揭示了构建一个强大系统并保持简单性的一条道路：显然。假设构建一个分布式系统的时间从几年降到几周，那么构建一个独立的庞大系统的复杂性就会消失，而这样的情况的出现，一定是由于出现了更可靠、更灵活的“积木” 。
2.12.2 Log在系统构建中的地位
假设一个系统。有了外部log系统的支持。那么每一个独立的系统就能够通过共享log来减少其自身的复杂性，Jay哥觉得log的作用是：
1) 处理数据一致性问题。不管是马上一致性还是终于一致性，都能够通过序列化对于节点的并发操作来达到。
2) 在节点间提供数据复制。
3) 提供“提交”的语义。
比方。在你觉得你的写操作不会丢失的情况下进行操作确认。
4) 提供外部系统可订阅的数据源(feeds) 。
5) 当节点因失败而丢失数据时，提供恢复的能力。或者又一次构建新的复制节点。

我所读过的最好的一篇分布式技术文章 学习笔记:The Log( 八 )

我所读过的最好的一篇分布式技术文章学习笔记:The Log( 八 )