为读写用。•
关于如何设置 值需要考虑的因素。一个 只能被一个消费者消费（一个
消费者可以同时消费多个 ），因此，如果设置的 的数量小于
的数量，就会有消费者消费不到数据。所以，推荐 的数量一定要大
于同时运行的 的数量。另外一方面，建议 的数量大于集群
的数量，这样 就可以均匀的分布在各个 中，最终使得集群负载
均衡。在 每个 都有上百个 。需要注意的是， 需要为每个
分配一些内存来缓存消息数据，如果 数量越大，就要为 分配更
大的 #。
直接发送消息到 上的 ，不需要经过任何中介一系列
的路由转发。为了实现这个特性， 集群中的每个 都可以响应 的请
求，并返回 的一些元信息，这些元信息包括哪些机器是存活的， 的
都在哪，现阶段哪些 是可以直接被访问的。•
客户端自己控制着消息被推送到哪些 。实现的方式可以是随机分配、
实现一类随机负载均衡算法，或者指定一些分区算法。 提供了接口供用户实现自定
义的分区，用户可以为每个消息指定一个 $，通过这个 $ 来实现一些 ##
分区算法。比如，把 作为 $ 的话，相同 的消息将会被推送到同
一个分区。•
以 # 的方式推送数据可以极大的提高处理效率，可以将消息在内存
中累计到一定数量后作为一个 # 发送请求。# 的数量大小可以通过 的
参数控制，参数值可以设置为累计的消息的数量（如 %&& 条）、累计的时间间隔（如
&&）或者累计的数据大小'(。通过增加 # 的大小，可以减少网络请求和磁
盘 )* 的次数，当然具体参数设置需要在效率和时效性方面做一个权衡。•
可以异步的并行的向 发送消息，但是通常 在发送完消息之后
会得到一个 响应，返回的是 值或者发送过程中遇到的错误。这其中有个非
常重要的参数“+这个参数决定了 要求 收到确认的副本
个数，如果 设置数量为 &，表示 不会等待 的响应，所以，
无法知道消息是否发送成功，这样有可能会导致数据丢失，但同时， 值为
& 会得到最大的系统吞吐量。•
若 设置为 ，表示 会在 收到消息时得到 的一个
确认，这样会有更好的可靠性，因为客户端会等待直到 确认收到消息。若设置为,
， 会在所有备份的 收到消息时得到 的确认，这个设置可以
得到最高的可靠性保证。•
消息有一个定长的 # 和变长的字节数组组成。因为 消息支持字节数组，
也就使得 可以支持任何用户自定义的序列号格式或者其它已有的格式如 -#
-.、 等。 没有限定单个消息的大小，但我们推荐消息大小不要超过
/通常一般消息大小都在 0 & 之前。
评论0