|
锁定老帖子 主题：帖子 博客等资源点击量缓存杀手级解决方案
精华帖 (0) :: 良好帖 (9) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-20
最后修改：2009-07-20
用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。 
|
| 返回顶楼 | |
|
发表时间：2009-07-20
srdrm 写道 量或许是很大, 但一天之内有hit的贴子量不会是这种100w量级的, 10w量级的贴子更新数我认为对于网站来说不小了. 刷到数据库不一定要同时刷, 这个不要求即时的,可以悠着点来,怎么悠怎么来,只要在一个合理时间内完成就行
sorry 怪我前面没讲清除 这里缓存的不仅仅是帖子的点击量，还包括博客 相片 新闻 圈子 等等吧 所有这些点击量都是缓存在一起的 对一般的网站这个量还是不小的 |
| 返回顶楼 | |
|
发表时间：2009-07-20
wulinux 写道 用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。
jms确实可以降低服务器的瞬间压力，实际上却没有节省资源 我的方案更强调的是节省资源 |
| 返回顶楼 | |
|
发表时间：2009-07-20
icefishc 写道 xly_971223 写道 srdrm 写道 用得着这么复杂吗, 我定个时间, 每隔30分钟将所有贴子的hits缓存刷到数据库中, 或者10分钟. 或者, 任意定个时间, 至少能解决绝大部分问题
如果缓存了10w帖子 假设有1w个发生了变化 你刷到数据库看看 1W条sql几乎同时到服务器不搞死才怪 10w对一个网站来说是非常小的数目了 如果是100W 1000W呢？ 小数目?? 什么网站可以有30min分钟10w条帖子的量? 好奇中. 引用 mock1234 写道 xly_971223 写道 mock1234 写道 使用线程中的线程将 +1 操作异步执行到数据库就可以了，不要搞复杂设计。 这会搞死数据库的 怎么搞死？有根据吗？ 这个.... 我无语了 性能这东西不是蒙出来的. 况且你连数据规模都不知道..... 关于你的那个测试 由于只有结果没有过程不好评论. http://xuliangyong.iteye.com/blog/424921 但你的结果和预想的实在相差太远. 怀疑造成这么大性能差距是由于其它的原因造成的． 麻烦仁兄帮测一下行不 
|
| 返回顶楼 | |
|
发表时间：2009-07-20
就算存在这么大的量, 数据库该不会是一个就搞定了吧. 机器也不只一台吧.
|
| 返回顶楼 | |
|
发表时间：2009-07-20
xly_971223 写道 wulinux 写道 用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。
jms确实可以降低服务器的瞬间压力，实际上却没有节省资源 我的方案更强调的是节省资源 你的提法确实可以节省资源，但是你可以保证你的机器不崩溃吗？ 如果系统死了，你前面9次修改的东西都丢失了，你的用户是否可以接受呢？ |
| 返回顶楼 | |
|
发表时间：2009-07-20
wulinux 写道 xly_971223 写道 wulinux 写道 用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。
jms确实可以降低服务器的瞬间压力，实际上却没有节省资源 我的方案更强调的是节省资源 你的提法确实可以节省资源，但是你可以保证你的机器不崩溃吗？ 如果系统死了，你前面9次修改的东西都丢失了，你的用户是否可以接受呢？ 说的没错 这也是我一直担心的问题，要解决这个问题就扯出缓存事务了 那问题就搞复杂了 另外 像点击量这种不是特别重要的数据有点偏差也是可以的 |
| 返回顶楼 | |
|
发表时间：2009-07-20
wulinux 写道 用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。
这里有一个问题： 在发出JMS到服务器和收到数据更新的成功的通知后，不能直接清除原来的数据，因为期间可能会有数据变动，如果Cache和db 中的相等，则用db的数据，如果cache中更大，则继续用cache中的数据 |
| 返回顶楼 | |
|
发表时间：2009-07-20
vampire423 写道 wulinux 写道 用JMS解决呀。
当前端更新了以后， 把变化的内容用JMS的形式发送到后台。后台线程接受到后，更新数据库。 这个过程不需要同步，可以允许有滞后。这样可以非常有效的解决你数据库服务器的压力。数据库更新成功后发一个JMS到缓存系统，把原来的数据清除掉，重新从数据库读出数据。我觉得这样可以解决你的问题了。
这里有一个问题： 在发出JMS到服务器和收到数据更新的成功的通知后，不能直接清除原来的数据，因为期间可能会有数据变动，如果Cache和db 中的相等，则用db的数据，如果cache中更大，则继续用cache中的数据 这样也行，你更新cache数据的时候比较一下， 如果已经更改了，就还用cache中的数据。 就算你一个网站有10万条记录更新，如果分散在一天中更新数据库，对数据库也是没有什么压力的。 你还要节约的话，就每次更新设一个时间限制，比如5分钟。也就是说你的更新Message延迟5分钟再发，如果你的点击数在五分钟里有又跟新了 就用新的数据。要不然就用老的。这样可以防止一篇帖子连续被点击，对数据库的压力突然增大。 |
| 返回顶楼 | |
|
发表时间：2009-07-21
lz提供了一个很好的思路呀。但是当文件导入库的时候，若数据量过大，也会对数据库造成超重负荷呀？
|
| 返回顶楼 | |
