1
88250 2014-05-13 09:03:26 +08:00
代码层面,为了满足一些特殊的需要,比如多实例。
|
2
vietor 2014-05-13 09:11:41 +08:00
我们换成了MongoDB,之后用Sharding。
|
4
cevincheung OP @88250 多实例?强制指定连接某台服务器而不是随机抽取slave或master?
|
5
cevincheung OP @vietor 的确,mongodb的话,自身已经做了类似mysql-proxy的很多工作了
|
6
saihuang 2014-05-13 10:27:56 +08:00
刚开始基本都是在代码层面来做吧
|
8
cevincheung OP |
9
MasterYoda 2014-05-13 12:46:58 +08:00
开始都是代码层面上做吧,简单shard之类的。
公司的业务做到后面一般会使用proxy,因为写业务逻辑的人可能根本不知道分表逻辑。 对他们屏蔽底层细节,降低耦合。 个人项目的话,无所谓吧。 |
10
cevincheung OP @MasterYoda 开发测试环境是内网linux,已经装有atlas了,所以一开始就是中间件的开发环境,分表什么的配置都在中间件中配置,感觉还ok。
mysql实时同步有什么好的建议?mysql replication异步容易延迟。 |
11
Admstor 2014-05-13 16:32:06 +08:00
mysql同步机制决定了几乎不存在"实时"同步
数据写入master,master生成bin-log,slave读取bin-log,slave执行bin-log 每一个都可能产生很高的延迟... |
12
MasterYoda 2014-05-13 16:56:34 +08:00
@cevincheung 容易延迟是肯定的,还是要看延迟的原因,如果确定是由于写入量过大导致的(因为master可以多线程写,slave却只能单线程同步),可以考虑使用多线程的同步工具,记得淘宝的mysql组有过成熟的解决方案。
当然延迟也有可能是网络延迟导致的,或者slave机器配置很差或者负载过高。不同原因不同解决思路。 |
13
vietor 2014-05-13 18:29:22 +08:00
|
14
GTim 2014-05-14 09:39:23 +08:00
@cevincheung 同步方面,其中一个就是采用/*master*/开头把语句导向主库,另外一个就是先放到缓存里 读的时候先读缓存
|