传统同步或者异步写到其他存储

多写入端，无法保证全部写入事务性，准确性，顺序性受限网络、不同终端性能、复杂拓扑等问题，对生产系统产生耦合性太强。性能也受到严重制约跨机房，下游变更，业务修改等都会对生产系统产生影响

使用kbus数据总线异步处理数据流能更灵活的应对各种架构演变，解耦生产系统和消费系统。以及跨机房，甚至跨语言带来的各种复杂性。

  1. 使用服务化方式发布，业务端和中间件完全解耦合。

    • 只暴露给用户最简单、最易用的消费功能API，减少用户的学习成本，使用成本
    • 业务不需要频繁升级就可以享受各种KBus的新优化和新功能
    • 在公司内部出现大促活动或者其他大的基础设施变更时，涉及的流量/机器调度、服务保障等都不需要用户过多介入。涉及到多机房异地机房变更等各种底层设施变化也都平滑给用户提供解决方案，让用户无感知

  2. 一处生产，处处消费设计理念。

    • 用户不需要关心数据输入源，只需要KBus这边启动server端，用户可以在任何机房启动消费
    • 可进行跨AZ/Region消费。用户不需要在需要消费的AZ或region部署生产源就可以直接消费，只要有一处源头生产端即可

  3. 提供用户可定制的托管化通用消费方案（如同步mysql到缓存，同步mysql到es，消费mysql到大数据等托管服务）

    • 用户通过KBus admin管理台配置平台提供的通用消费方案，即可直接启动托管消费。不需要用户写代码，也不需要用户上线服务。保证在半天内上线用户通用功能

  4. 提供事务性消费支持。用户可按照事务维度进行消费，保证业务在同一事务内的数据可联动处理业务逻辑。

  5. 提供给用户高性能多样性的顺序消费方案。可以让用户在进行顺序性消费要求时，解决用户只能单机顺序消费一个数据库的性能瓶颈。KBus提供在服务端定制多样性顺序生产，下游可多个实例对数据顺序消费，提供客户端的消费能力上限。

  6. KBus提供根据时间回溯消费功能。如可以让业务对回溯因为上线导致消费不对进行回溯一段时间内的内容

    同步

    先删除 cache ，后更新 db

    请求 1 先把 cache 中的 A 数据删除 -> 请求 2 从 db 中读取数据->请求 1 再把 db 中的 A 数据更新->请求 2将数据 A 写入 cache

    先更新 db ，后删除cache

    请求 1 从 db 读数据 A-> 请求 2 更新 db 中的数据 A（此时缓存中无数据 A ，故不用执行删除缓存操作 ） -> 请求 1 将数据 A 写入 cache

    延迟X毫秒删除缓存主要的意义在于：1. 有可能之前缓存里写入了脏数据，删除缓存可以清空掉脏数据；2. 删除缓存后，下次读会回源db，因为延迟了x毫秒才删除，这x毫秒主要是保证db主从已经完成同步，这时候再从从库回源依然能读到正确的数据

    kubs

    产生不一致的过程为:

    1. 请求A，发起读请求，发现缓存中没有数据

    2. 请求A，从DB进行回源，从DB中读到的数据为V1

    3. 请求B，发起写请求，将DB中的数据更新为V2

    4. KBUS，消费到更新的binlog，将缓存更新为V2

    5. 请求A，将从DB回源读到的数据V1，写回redis

      用setnx指令来替代set指令

kbus-overview-3