我正在将我的应用程序从riak 1.4迁移到riak 2。
在过去，我一直将我的应用程序集中在riak集群的每个节点上。它只连接到本地riak节点（在 localhost:8087 )，监控riak的可用性，并在此基础上宣传其自身的可用性。远程haproxies监视这些应用程序中的多个，并将最终用户流量定向到任何可用的应用程序示例：
最终用户--网络-->haproxy--网络-->池[应用程序->riak]
我选择这种架构的理由是
应用程序和riak之间的最低可能延迟
如果应用程序的conf为零，它总是希望本地主机上有riak
haproxy交通分布的良好控制（仅在那里）
良好的安全性：protobuf只暴露于localhost
java客户机文档现在建议，在连接时，riak客户机应用程序应该知道riak集群的所有节点。有鉴于此，我的做法还可以接受吗？或者我应该切换到这样一个场景：应用程序的每个示例都知道并连接到每个riak节点？
1条答案
按热度按时间q43xntqr1#
我相信客户机有两个目的来了解每个节点
当单个riak节点关闭时，应用程序节点仍然可用
单个重载的应用程序节点不会将其所有负载转移到单个riak节点
直接向主节点提交写操作，而不是提交到必须转发请求的随机节点，这有一个性能提升（在dynamo白皮书中有提到）
看起来，在您的情况下，haproxy已经在处理单个应用程序节点的可用性和负载平衡，而且您还没有利用性能差异。
在客户机中维护连接池并不是什么新鲜事，我相信1.4客户机中已经有了。如果您以前不需要它，那么现在添加它是有意义的，如果您还计划进行其他更改以利用连接池的好处。