往往大数据量,高并发时, 瓶颈都在 数据库 上, 好多人都说用 数据库的 复制,发布, 读写分离等技术, 但 主从数据库之间同步时间 有 延迟. 这个怎么解决啊? 最好希望同步的延迟为0,有终级解决方案吗? 或者说下思路,谢谢
凡是大型的系统,必然要分库,也就是根据逻辑进行数据拆分。比如用户的数据,你可以根据用户所在的省份划分,一个省份一个数据库,只有这样才能真正的保证大数量的并发。
另外要有效的利用读写分离,读写分离用sql server 2012的话可以直接用always on,一个用来写,若干用来读。数据库自身会保证数据的一致性的,这样就不会出现查备份库数据还没同步过来的问题了。
能给我简单说一下,分库要看哪些知识点吗,小女子感激不尽
@Cristic: 我觉得分库要看具体的应用场景,水平分或者竖直分。不过通常而言,水平分可能更多一些,因为当某些表的记录数达到一个很大值(比如上亿),那么水平分更有效一点。基本原则则是保证在一个事务场景中,能用一个库搞定,不出现两个库之间的关联查询。分库还要根据实际的应用场景,比如我们是按照用户来划分,还是按照地域来划分等等,在一个应用的初始设计中,你是无法预估的,这个需要边上线,边分析用户数据,边改进结构。在没有大量用户使用的前提下(也就是缺少必要的数据使用分析),光凭脑袋空想分库场景基本是不现实的。
@ocean: 嗯谢谢了,收益匪浅
只要是同步,就不可能为零延迟,你的需求更多应该是出现在分析上。
数据库瓶颈其实是CPU、内存、硬盘读写性能的瓶颈,这些通常都有空间可以优化。
但最大的瓶颈经常是出现在解决方案的设计上,我觉得你更大的问题是分析问题解决问题的思路。
世界上任何的一种解决方案都是有瓶颈的,就象IPHONE电池不可更换,但可以接受。
通常采用读写分离的设计,就是可以接受延迟的。
你的主从如何设计的?
就是多个数据库之间同步, 一个写, 多个读. 得解决延迟问题啊
@mick100ey: 如果想简单的解决数据库之间的同步问题,最好的方法就是直接采用支持这些特性的数据库,比如sql server 2012的always on特性,就已经帮你解决好了相应的问题。当然如果你自己做这些逻辑自然就会花费很多的精力并且也不见得能保证稳定性。
读写分离+前端Js控制效果,主服务写,备份服务器读数据。
前端JS控制, 删除了, 但用户一刷新页面, 被删除的,又回来了.(因为查的是备份库,此时 还没有同步完成的话)
这样 测试会说这是Bug ,用户会认为这系统不靠谱.
你说,等3分钟后 数据库同步完成了,你再刷新 被册的, 不会回来了.
这时用户会举例子,某某网, 那么多人使用,也没有出现这样的Bug的.
像QQ空间这么多人使用,也没发现 删除了 ,刷新后重新回来的情况啊 ^_^
其实每一个大数据并发负载方案,都有其数据分布,业务处理因素的特定性,比如在电子商务网站中,商品展示,读多写少,订单数据写多读少,根据这样一些特性,分别制定特定的方案。在存储方面,对于硬件,离cpu越近,速度越快,cpu一级缓存》cpu二级缓存>内存>硬盘。
使用nosql 内存数据库,百度 erpcore , 这是个国人开发的高并发开发框架