LinkedIn开源大数据，千次数据吞吐变更

    从LinkedIn 正式进入生产系统。整个生态系统中就需要一个可靠的、支持事务的、保持一致性的数据变更抓取系统。LinkedIn 内部有很多专用的数据存储和服务系统，构成了一个多种多样的生态系统。基础的 OLTP 数据存储用来处理面向用户的写操作和部分读操作。其他专用系统提供负责查询，或者通过缓存用来加速查询结果。
    Databus 就是一个实时的低延迟数据抓取系统。
    在 Databus 的 Github 页面上，介绍了他们选择目前解决方案的决策过程。
    LinkedIn开源大数据，千次数据吞吐变更，处理这种需求有两种常用方式：
    这种模式下，应用层同时向数据库和另一个消息系统发起写操作。这种实现看起来简单，因为可以控制向数据库写的应用代码。但是，它会引入一致性问题，因为没有复杂的协调协议（比如两阶段提交协议或者 paxos 算法），所以当出现问题时，很难保证数据库和消息系统完全处于相同的锁定状态。两个系统需要精确完成同样的写操作，并以同样的顺序完成序列化。如果写操作是有条件的或是有部分更新的语义，那么事情就会变得更麻烦。
    数据库日志挖掘：将数据库作为唯一真实数据来源，并将变更从事务或提交日志中提取出来。这可以解决一致性问题，但是很难实现，因为 Oracle 和 MySQL 这样的数据库有私有的交易日志格式和复制冗余解决方案，难以保证版本升级之后的可用性。由于要解决的是处理应用代码发起的数据变更，然后写入到另一个数据库中，冗余系统就得是用户层面的，而且要与来源无关。
    在评估了两种方式的优劣之后，我们决定选择日志挖掘，将一致性和单一真实数据来源作为最高优先级，而不是易于实现。

    这种与数据来源的独立性非常重要，可以避免应用栈的技术锁定，或是绑死在二进制格式上。Databus 的传输层端到端延迟是微秒级的，每台服务器每秒可以处理数千次数据吞吐变更事件，同时还支持无限回溯能力和丰富的变更订阅功能。