Please enable JavaScript.

Coggle requires JavaScript to display documents.

为什么不能保证 Exactly-once, 熔断机制的关键点, 为什么需要限流, 限流算法, 大数据分析场景的数据处理一般有以下的特点,…

- - - - 如果上一个统计周期的流量集中在最后 10 ms ，而现在这个统计周期的流量集中在前 10 ms ，那么这 20 ms 的时间内会出现 200 次调用，这就超过了我们预期的 2 秒内不能超过 100 次请求的目的了。这时候，我们就需要使用“滑动窗口”算法来改善这个问题了。
      - 由于流量突增使请求超过预期，导致流量可能在一个统计周期的前 10 ms 内就达到了 100 次，给服务的处理能力造成一定压力，同时后面的 1990 ms 将会触发限流。这个问题虽然可以通过减小统计周期来改善，但是因为统计周期变小，每个周期的阈值也会变小，一个小的流量抖动就会导致限流的发生，所以系统的抗抖动能力就变得更差了。
- - - - 最后，由于服务内部出现严重的过载，导致响应严重超时，服务的调用方同样会出现大量请求的积压使资源耗尽，这样正反馈循环就形成了，故障沿着调用链路逆向传播，导致整个系统出现雪崩
- - - - 总体来说，水平垂直分片策略不仅保留了列式存储的优点，而且将多列操作控制在一个数据分片上，减少了网络 IO 和分布式事务，是混合分片策略常见的方式，Google 的 Dremel 数据库就采用了这种分片策略。
- - - - 限制重试的次数
        
        如果重试 3 次都失败了，就直接返回请求失败，不再继续重试
      - 重试的间隔
        
        取指数退避的策略，比如重试 3 次，第一次请求失败后，等待 1 秒再进行重试，如果再次失败，就等待 3 秒再进行重试，仍然失败的话，就等待 9 秒后再进行重试
- - - - 通过上文对熔断机制的讨论，我们将服务由于过载原因导致的错误比例，作为熔断器断开的阈值，当被调用服务出现过载的时候，熔断器通过错误比例感知到被调用服务过载后，就立即将调用请求返回错误，这样可以减少被调用服务的请求数量，也可以减少调用服务由于等待请求响应而积压的请求，完美切断了正反馈循环，确保了雪崩不会发生
- - - - 所以，我认为系统能否利用公有云或私有云进行弹性扩容，是云原生系统的核心标志。并且在以后，扩容将是解决系统过载问题最常用的方法。
- - - - 基于关键词划分也会带来问题，即数据分布不均匀和访问的热度不均匀
        
        基于关键词划分，很明显会使数据分布和关键词自身的分布保持一致。
        
        其实基于关键词的 Hash 值划分就可以解决这些问题，它通过对关键词进行 Hash 运算，然后基于计算后的 Hash 值范围对数据进行划分，一个好的 Hash 算法可以处理数据倾斜并让它均匀分布。这里我们可以理解为通过 Hash 运算，去除了关键词数据分布的业务属性，从而解决了数据分布和访问的热度不均匀的问题。
        
        ，基于关键词的 Hash 值划分，带来了数据分布和访问热度更均匀的优点，但同时，它也失去了基于关键词的顺序性，不能方便地通过关键词进行区间查询了。并且，在极端情况下，如果一个关键词的访问热度非常大，那么基于关键词的 Hash 值划分也完全不起作用了。
- - - - 对于动态分片，因为在运行时，分片区间是可以进行分裂和合并的，所以我们不用担心不了解数据分布，而导致分片区间划分不合理的情况，也不用担心在分片区间划分后，数据的分布发生变化，使分片区间不合适的问题。总而言之，动态分片与基于关键词的划分，往往是一个比较好的组合方式，它避免了基于关键词划分的问题，还保留了数据基于关键词有序的优点。
        
        在基于关键词的划分中，基于自增 ID 或者时间戳等原因，导致的访问冷热不均匀的问题，即使是在动态分片中也不能很好地解决，因为数据的热点往往集中在最新的一个分片区间上。而基于关键词的 Hash 值划分的方式，则可以很方便地将最新的热点数据分布到多个分片上，很好地解决这个问题
        
        动态分片在冷启动时，预分裂为多个分片来缓解。