Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

关于读写分离

  最近做的项目由于某些层面特别不给力,结果不得不玩儿命地在程序方面做优化,读写分离就是其中一项重要措施。我觉得这对于一个完整的项目而言是必须的。其实就这个破博客程序都实现过读写分离,「读」由 PHP 负责,「写」则由 Node 负责。
  尽管「读」和「写」操作的目标对象都是数据,但它们是完全相反的操作,针对它们的优化方式也完全不同,把它们放在一起迟早会被坑到。

「读」操作

  读操作主要考虑的是各种缓存。数据库自带的查询缓存、后端程序自己实现的一套缓存、HTTP 这样的传输缓存、前端程序实现的缓存等。只要做好缓存就可以有效减少查询。这不但降低了服务器查询的压力,也可以让客户端更快地得到数据。有时候我甚至想把各种静态结果丢到 CDN 上,不过这确实有点丧病了。
  缓存最大的坑就是时机问题,什么时候该缓存?缓存多久?这是比较难界定的。之前的文章比如「前端缓存更新时机问题」也有提到这个问题。但对从前端到数据库这整套 Web 体系的缓存时机我还缺乏研究,这里就不扯淡了。

「写」操作

  写操作需要考虑的是数据应该以何种方式存储?临时的还是持久的?数据量有多大?可否放到内存里?操作过程中锁的性能瓶颈是否可以接受?甚至数据精确度要求不高的话可以考虑不加锁(脏就让它脏呗)。对于「写」操作优化我确实没什么经验,一直没接触过写频繁的场景,目前能做的只有合并事务之类的东西。也许做过网游服务器之类的才会考虑比较深入吧?我猜的~

总结

  读写分离应该不是「哪一层」才做的东西,而是所有层都做的。即使是数据库设计,如果把读频繁和写频繁的东西分表存储,后续的优化也可以省点力气。

网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^