需求：提高负载能力，由于表比较大，单表查询命令经过优化后延迟在 200 毫秒左右，已经很难再进一步优化，多线程下负载能力明显降低，同时能处理的并发数只有几十个。在网上调研了一下 oracle 的各类高可用集群方案，感觉面对这种场景都不太行，不能有效增加负载能力。
由于这部分业务只涉及大量读取，对一致性要求不高，感觉搞两个实例同时处理，一下子处理能力不就能翻倍了吗？于是想到一个办法，是有没有办法产生一种中间服务，比如绑定到 IP 10.0.2.22 ，然后由这个中间服务分别连接到若干个（个位数）的独立数据库节点，每次产生写入或者删除都自动在所有节点之间广播这种操作，搜索时候实现均衡负载？
 |
1
GlobalNPC Mar 23, 2021 via Android
Redis+分片？
|
 |
2
pisc Mar 23, 2021 via Android
随便一个成熟的分布式数据库都能满足你的需求
|
 |
3
soberYang Mar 23, 2021 via iPhone
直接操作多数据源，负载策略如果不需要通用的，就业务上轮询操作多个数据源。
|
|
4
pisc Mar 23, 2021 via Android
补充：指的是 new SQL 这种模型的分布式数据库，甚至如果查询不复杂的话，普通的分片中间件也是可以的，随便找个开源成熟的就行，舍得花钱的话，随便找个云服务商都有这种服务卖的
|
 |
5
sykmile Mar 23, 2021 via iPhone
配合项目代码实现的话 sharding jdbc 可以满足你的要求
|
 |
6
jacksparrow414 Mar 23, 2021  1
shanding jdbc 或者 sharding proxy
|
 |
7
stardustree Mar 23, 2021
只读嘛，随便搞个 proxy 就好了么，haproxy 欢迎你
|
 |
8
lostvincent Mar 23, 2021
就你的描述来说，想上中间件，但是做法又像主从，不知道你实际想要什么
就需求来说，读多写少，一致性要求还不高，那么 1. 就你说的那种做法，更像主从那套，主写从读，看业务自己估计几台从，配好了自动同步 优：简单方便，效果还行 缺：单表还是很大，增长快的话容易继续瓶颈 2. 分表分库，然后就你说的用中间件 优：后续扩展性好 缺：需要处理下现有数据，相对比较麻烦，视情况可能还需要修改业务代码 中间件的话，你看看 https://github.com/flike/kingshard 这类是不是你需要的 |
 |
9
zw1one Mar 23, 2021
为啥说 oracle 的集群方案不能有效增加负载能力？
一般你这个需求的处理思路都是数据库集群、分表分库、读写分离这些吧 |
 |
10
wakzz Mar 23, 2021
sharding proxy
|
 |
11
buchikoma Mar 23, 2021
参考下云厂商的金融版数据库，一主一从一只读
|
 |
12
LeeReamond OP @zw1one 分表拆不太开，子表方案测试过，拆了一万多张，性能反而下降很严重，目前用的表内分区的方案。orcl 的集群我不是很了解，网上资料没有 mysql 这么多，我查到 rac 集群的方案，感觉多实例读一块共享存储，不如多实例。还有一种方案也许是同表内多分区存在不同实例里，但我不会配，似乎也没有类似的方案
|
|
13
LeeReamond OP @lostvincent 感谢回复，我考虑了一下觉得我要的应该是主从，只是网上搜索信息一般集群指向 rac，似乎并非主从方案。
|
Select Language