内存型的甚至5万以上。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库 结构再开发的模式。
很多业务是可以用这类数据库来替代mysql的。
八、缓存。
数据库很脆弱，一定要有缓存在前面挡着，其实我们优化速度，几乎就是优化缓存，能用缓存的地方，就不要再跑到后端数据库那折腾。
缓存有持久化缓存、 内存缓存，生成静态页面是最容易理解的持久化缓存了，还有很多比如varnish的分块缓存、前面提到的memcachedb等，
内存缓 存，memcached、redis首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，
但容易引发雪崩效应，一旦缓存大面积失效，数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。
这两者之间如何配合，程序设计要多 动脑筋。
九、队列。
用户一个操作很可能引发一系列资源和功能的调动，这些调动如果同时发生，压力无法控制，用户体验也不好，可以把这样一些操作放入队列，
由另几个模块 去异步执行，例如发送邮件，发送手机短信。开源队列服务器很多，性能要求不高用数据库当做队列也可以，
只要保证程序读写队列的接口不变，底层队列服务可随 时更换就可以，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。
十、文件存储。
除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。
典型的就是图片，从用户头像到用户上传的照片，还要生成不 同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。
不使用专业存储的情况下，基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是非常容 易产生热点的，
有些图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也很耗费时间。
为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。很多网站都将cookie设置到了.domain.ltd，
如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。
如果用普通的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，这样第一级有16个目录。
从0 到F，可以把这个字母作为域名，0.yourimg.com到f.yourimg.com（客户端dns压力会增大），还可以扩展到最多16个NAS集群 上。
第二级可用年月例如，201011，第三级用日，第四级可选，根据上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件，避免计 算大量文件带来的开销。
当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。
下面，我们要谈谈代码了。
这一系列的最后一篇写给普通编程人员，如果不感兴趣可直接看本文最后几段。
开始设计代码结构之前，先回顾一下之前准备过的事情：我们有负载均衡的 WEB服务器，
有主从DB服务器并可能分片，有缓存，有可扩展的存储。在组织代码的各个方面，跟这些准备息息相关，
我一二三的列出来分别说，并且每一条都 以“前面讲到”这个经典句式开头，为了方便对照。
别着急看经典句式，我思维跳跃了，插一段。实际开发中，我们总会在性能和代码优雅性上作折中。
对于当今的计算机和语言解释器，多几层少几层对象调 用、声明变量为Map还是HashMap这种问题是最后才需要考虑的问题，
永远要考虑系统最慢的部分，从最慢的部分解决。例如看看你用的ORM是不是做了 很多你用不到的事情，是不是有重复的数据调用。
我们做的是web应用开发，不是底层框架API，代码易读易懂是保证质量很重要的一方面，你的程序是为了什 么而设计，