关于Ringpop，在Uber中使用的应用程序层分片

Question

https://ringpop.readthedocs.org/en/latest/

据我了解，可以在某些库例程中实现分片，并且应用程序仅与库链接。如果该库是RPC客户端，则可以从服务器端实时查询分片。因此，即使有一个新分区，它对应用程序也是透明的。

Ringpop是基于SWIM成员身份协议的应用程序层分片策略。我想知道应用程序层的主要优势是什么？

在系统层中分片又是另一面呢？

谢谢！

Answer 1

收到回复可能有点晚，但也许仍然有人需要此信息。

Ringpop引入了在应用程序内部而不是数据内部进行“分片”的想法。它或多或少地像应用程序级中间件一样工作，但是它的优点是提供了一种构建可伸缩和容错应用程序的简便方法。

Ringpop分片的内容是来自客户端对特定服务的请求。这是它的主要优点之一（有更多优点，请继续阅读）。

在传统的SOA架构中，对特定服务的所有请求都转到一个独特的系统，该系统将这些请求分配给工作人员以进行负载平衡。这些工人彼此不认识，他们是独立的实体，无法在他们之间进行交流。他们完成了工作，并发回了答复。

流行音乐则相反：工人彼此了解并可以发现新的，定期与他们交谈以检查其健康状况，并与其他工人一起传播此信息。

Ringpop如何分摊请求？它使用键空间的概念。键空间只是一个数字范围，例如，您可以自由选择自己喜欢的范围，但是显而易见的选择是对应用程序中对象的ID进行哈希处理，并使用哈希函数的共域作为范围。

键空间可以想象为散列“环”，但实际上只是4或8字节的整数。

工作人员（例如可以为特定服务的请求服务的节点）“虚拟地”放置在此环上，例如它拥有该环的连续部分。实际上，它已分配了一个子范围。工作人员负责处理属于其子范围的所有请求。处理请求意味着两件事：-处理请求并提供响应，或-将请求转发给实际上知道如何服务该请求的另一服务

每个应用程序都将嵌入此行为。存在处理请求或将其转发到可以处理该请求的其他服务的逻辑。转发机制不过是一个远程调用过程，它实际上是使用TChannel（Uber针对通用RPC的高性能转发）完成的。

如果您对此进行考虑，则可以发现Ringpop实际上提供了传统SOA架构所没有的非常好的东西。客户不需要知道或关心可以满足其请求的正确实例。他们可以在Ringpop中的任何地方发送请求，接收方工作人员将为您提供服务或转发给严格的所有者。

铃声有另一个有趣的功能。新员工可以生气勃勃地进入环网，而旧员工可以离开环网（例如，由于崩溃或停机），而无需任何服务干扰。Ringpop实现基于SWIM的成员身份协议。它使工作人员能够发现彼此，并使用基于tcp的八卦协议将坏掉的工作人员从环中排除。当另一位工人发现新工人时，他们之间将建立新的连接。每个工作人员都按固定的时间间隔映射发送ping请求的其他工作人员的状态，如果ping无法收到答复，则将状态信息与其他工作人员一起传播（例如，基于ping /八卦的piggy带成员更新）

这3个元素保持一致的哈希，请求转发和成员身份协议，使Ringpop成为一种有趣的解决方案，可以在应用程序层提高可伸缩性和容错能力，同时将复杂性和运营开销保持在最低水平。