不考虑dz这样的（不是做产品往外卖，自己运营层面的）
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 4566 days ago, the information mentioned may be changed or developed.
 |
88250May 13, 2014
1
代码层面，为了满足一些特殊的需要，比如多实例。
|
 |
vietorMay 13, 2014
2
我们换成了MongoDB，之后用Sharding。
|
 |
4
@88250 多实例？强制指定连接某台服务器而不是随机抽取slave或master？
|
|
5
@vietor 的确，mongodb的话，自身已经做了类似mysql-proxy的很多工作了
|
 |
saihuangMay 13, 2014
6
刚开始基本都是在代码层面来做吧
|
|
8
|
2 |
MasterYodaMay 13, 2014
9
开始都是代码层面上做吧，简单shard之类的。
公司的业务做到后面一般会使用proxy，因为写业务逻辑的人可能根本不知道分表逻辑。 对他们屏蔽底层细节，降低耦合。 个人项目的话，无所谓吧。 |
|
10
@MasterYoda 开发测试环境是内网linux，已经装有atlas了，所以一开始就是中间件的开发环境，分表什么的配置都在中间件中配置，感觉还ok。
mysql实时同步有什么好的建议？mysql replication异步容易延迟。 |
 |
VorenMay 13, 2014
11
mysql同步机制决定了几乎不存在"实时"同步
数据写入master,master生成bin-log,slave读取bin-log,slave执行bin-log 每一个都可能产生很高的延迟... |
|
MasterYodaMay 13, 2014
12
@cevincheung 容易延迟是肯定的，还是要看延迟的原因，如果确定是由于写入量过大导致的（因为master可以多线程写，slave却只能单线程同步），可以考虑使用多线程的同步工具，记得淘宝的mysql组有过成熟的解决方案。
当然延迟也有可能是网络延迟导致的，或者slave机器配置很差或者负载过高。不同原因不同解决思路。 |
|
vietorMay 13, 2014
13
|
 |
yemoluoMay 14, 2014
14
@cevincheung 同步方面，其中一个就是采用/*master*/开头把语句导向主库，另外一个就是先放到缓存里 读的时候先读缓存
|
Select Language