优化一个分布式系统的吞吐能力,除了应用本身代码外,很大程度上是在优化它所依赖的中间件集群处理能力。如:kafka/redis/rabbitmq/postgresql/分布式存储(CephFS,JuiceFS,C urve,Longhorn)等集群的处理能力。
优化一个分布式系统的吞吐能力,除了应用本身代码外,很大程度上是在优化它所依赖的中间件集群处理能力。如:kafka/redis/rabbitmq/postgresql/分布式存储(CephFS,JuiceFS,C urve,Longhorn)等集群的处理能力。
分布式存储集群(Longhorn)
这里主要用于Citus集群的协调器(coordinator)和工作器(worker)节点的数据持久化。
具体文档,请参阅:https://longhorn.io/
分布式 PostgreSQL 集群(Citus)
这里主要用于对Sentry事件源数据大表nodestore_node的分片。
具体文档,请参阅:
https://docs.citusdata.com/en/v11.1/
读写分离和高可用(PgPool+Repmgr)
这里主要用于对Citus节点(协调器/工作器)进行读写分离和主备高可用。
具体文档,请参阅:
https://www.pgpool.net/docs/pgpool-II-4.2.3/en/html/example-kubernetes.html
https://repmgr.org/
管理集群节点(PgAdmin)
具体文档,请参阅:
https://www.pgadmin.org/
nodestore_node 大表分片
选择分布式 key,并将表转换分布式表,这里将表划分为64个分片,数据平均分配到6台worker节点:
# 创建分布式表
SELECT create_distributed_table('nodestore_node', 'id', colocate_with => 'none', shard_count => 64);
# 平衡分片
SELECT rebalance_table_shards();
# 查询分片
SELECT * FROM citus_shards;
总结
中间件集群基础设施建设,本身涉及细节较多,可以说是另一个领域。
本文提供了一种笔者的实践思路,抛砖引玉。
©本文为清一色官方代发,观点仅代表作者本人,与清一色无关。清一色对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议,请读者仅作参考,并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络,如侵犯到著作权人的权利,请与我们联系(微信/QQ:1074760229)。转载请注明出处:清一色财经