不用把未来的用户量想的太夸张,当前的单服务器硬件性能足够支撑起绝大部分网站应用,当有一天真有那么大的用户量你估计就有自己的思路了
呵呵,我现在就想知道啊。一方面是未雨绸缪,另一方面是想知道牛人是怎么做的,学习学习,提升自己
@平和的心: 我们用RabbitMQ队列服务,然后开多个消费端往数据库里写,写入的时候采用一些策略(在事务中批量插入,MySql开个事务批量插入和不开事务直接多条插入性能差的很多)
队列服务支持集群,消费端也有多个,性能和容错也算是个平衡,任何一台机器挂了都不会有多大影响,横向扩展能力也OK
@The Soul Render: 多谢分享
@The Soul Render: 有一个问题,如果在写入持久化数据库之前,用户来查询,那怎么办?是不是要用memcached等缓存数据库,把查询的数据缓存起来,用户每次写入时先更新memcached,同时写入RabbitMQ队列,用户查询时,用memcached?
@平和的心: 首先是前端处理,消息发送到队列后AJAX就会返回响应了,这时候就会直接在页面上显示出用户发的内容.
微博类的页面一般都会大量使用脚本和AJAX做一些动态更新内容之类的功能,很少有用户去刷新整个页面的.
而且在这种处理结构下队列中积压过多数据(几秒或几分钟都没处理完)的话首先要考虑的就应该是消费端少了(增加消费端)或者数据库性能支撑不住了(买更好的服务器,分库,分表)
memcached不是银弹,要小心使用,有时候用的过多了会有反作用的
量再大一些可以考虑增加Redis,对List和Set的支持比memcached好,memcached在处理集合时需要依赖序列化和反序列化对性能的影响还是比较大的
发的时候,是直接显示在界面上的,这个时候还没有存入数据库吧。写入估计有排队机制吧。
对于微博、评论这样的数据,对可用性要求不算太高的,可以选择采用Nosql来解决。
你确定是这样吗?如果是这样的话,那我发了评论后,立马Ctrl+F5,应该就没了吧,可事实不是这样
@平和的心: ...你这个立马,已经好几s了。数据库延迟不会那么慢的!
@幻天芒: 你可以在发微博的时候打开开发者工具栏,你可以看看是先显示,还是等请求响应。
@幻天芒: 我用firebug看了一下,但看不出来啊,因为post响应也很快
@平和的心: 你看响应的结果呗。
@幻天芒: 恩,我在http://tech.sina.com.cn/i/2010-11-16/14434871585.shtml中找到了,它们的确有一个消息队列,微博塞入消息队列后就给用户响应了,响应后才显示的。这就是说他们只用消息队列就可以了解决高频率写入的压力?
@平和的心: 消息队列可以避锋.
@吴瑞祥: 那除了消息队列之外,有没有没其它策略?
@平和的心: 用上消息队列,能够先不看持久化结果,直接对请求进行响应。这样只是缓解了压力。
多台数据库服务器集群处理怎么样;数据量大的表水平分割到多个库
----------
微博等应该是读多写少,可以把热门条目放到高速缓冲中(内存)
楼主:看看这两篇文章对你有帮助没
http://server.51cto.com/sCollege-365024.htm
http://www.infoq.com/cn/interviews/jf-taobao-database
非常感谢