Memcache and Mongodb
先说说自己对Memcache和Mongodb的一些看法，主要是抛砖引玉了，希望看到大家的意见和补充。
Memcache
Memcache的优势我觉得总结下来主要体现在：
1）分布式。可以由10台拥有4G内存的机器，构成一个40G的内存池，如果觉得还不够大可以增加机器，这样一个大的内存池，完全可以把大部分热点业务数据保存进去，由内存来阻挡大部分对数据库读的请求，对数据库释放可观的压力。
2）单点。如果Web服务器或App服务器做负载均衡的话，在各自内存中保存的缓存可能各不相同，如果数据需要同步的话，比较麻烦（各自自己过期，还是分发数据同步？），即使数据并不需要同步，用户也可能因为数据的不一致而产生用户体验上的不友好。
3）性能强。不用怀疑和数据库相比确实是，根源上还是内存的读写和磁盘读写效率上几个数量级的差距。有的时候我们在抱怨数据库读写太差的情况下可以看看磁盘的IO，如果确实是瓶颈的话装啥强劲的数据库估计也档不了，强不强无非是这个数据库多少充分的利用了内存。
但是也不太建议在任何情况下使用Memcache替代任何缓存：
1）如果Value特别大，不太适合。因为在默认编译下Memcache只支持1M的Value（Key的限制到不是最大的问题）。其实从实践的角度来说也不建议把非常大的数据保存在Memcache中，因为有序列化反序列化的过程，别小看它消耗的CPU。说到这个就要提一下，我一直觉得Memcache适合面向输出的内容缓存，而不是面向处理的数据缓存，也就是不太适合把大块数据放进去拿出来处理之后再放进去，而是适合拿出来就直接给输出了，或是拿出来不需要处理直接用。
2）如果不允许过期，不太适合。Memcache在默认情况下最大30天过期，而且在内存达到使用限制后它也会回收最少使用的数据。因此，如果我们要把它当作static变量的话就要考虑到这个问题，必须有重新初始化数据的过程。其实应该这么想，既然是缓存就是拿到了存起来，如果没有必定有一个重新获取重新缓存的过程，而不是想着它永远存在。
在使用Memcache的过程中当然也会有一些问题或者说最佳实践：
1）清除部分数据的问题。Memcache只是一个Key/Value的池，一个公共汽车谁都可以上。我觉得对于类似的公共资源，如果用的人都按照自己的规则来的话很容易出现问题。因此，最好在Key值的规范上上使用类似命名空间的概念，每一个用户都能很明确的知道某一块功能的Key的范围，或者说前缀。带来的好处是我们如果需要清空的话可以根据这个规范找到我们自己的一批Key然后再去清空，而不是清空所有的。当然有人是采用版本升级的概念，老的Key就让它过去吧，到时候自然会清空，这也是一种办法。不过Key有规范总是有好处的，在统计上也方便一点。
2）Value的组织问题。也就是说我们存的数据的粒度，比如要保存一个列表，是一个保存在一个键值还是统一保存为一个键值，这取决于业务。如果粒度很小的话最好是在获取的时候能批量获取，在保存的时候也能批量保存。对于跨网络的调用次数越少越好，可以想一下，如果一个页面需要输出100行数据，每一个数据都需要获取一次，一个页面进行上百次连接这个性能会不会成问题。
那么Memcache主要用在哪些功能上呢？
其实我觉得平时能想到在内存中做缓存的地方我们都可以考虑下是不是可以去适用分布式缓存，但是主要的用途还是用来在前端或中部挡一下读的需求来释放Web服务器App服务器以及DB的压力。
Mongodb
Mongodb是一款比较优良的非关系型数据库的文档型的数据库。它的优势主要体现在：
1）开源。意味着即使我们不去改也可以充分挖掘它，MSSQL除了看那些文档，谁又知道它内部如何实现。
2）免费。意味着我们可以在大量垃圾服务器上装大量的实例，即使它性能不怎么高，也架不住非常多的点啊。
3）性能高。其它没比较过，和MSSQL相比，同样的应用（主要是写操作）一个撑500用户就挂了，一个可以撑到2000。在数据量上到百万之后，即使没索引，MSSQL的插入性能下降的也一塌糊涂。其实任何事物都有相对性的，在变得复杂变得完善了之后会牺牲一部分的性能，MSSQL体现的是非常强的安全性数据完整性，这点是Mongodb办不到的。
4）配置简单并且灵活。在生产环境中对数据库配置故障转移群集和读写分离的数据库复制是很常见的需求，MSSQL的配置繁琐的步骤还是很恐怖的，而Mongodb可以在五分钟之内配置自己所需要的故障转移组，读写分离更是只需要一分钟。灵活性体现在，我们可以配置一个M一个S，两个M一个S（两个M写入的数据会合并到S上供读取），一个M两个S（一个M写入的数据在两个S上有镜像），甚至是多个M多个S（理论上可以创建10个M，10个S，我们只需要通过轮询方式随便往哪个M上写，需要读的时候也可以轮训任意一个S，当然我们要知道不可能保证在同一时间所有的S都有一致的数据）。那么也可以配置两个M的对作为一套故障转移群集，然后这样的群集配置两套，再对应两个S，也就是4个M对应2个S，保证M点具有故障转移。
5）使用灵活。在之前的文章中我提到甚至可以通过SQL到JS表达式的转换让Mongodb支持SQL语句的查询，不管怎么说Mongodb在查询上还是很方便的。
之前也说过了，并不是所有数据库应用都使用采用Mongodb来替代的，它的主要缺点是：
1）开源软件的特点：更新快，应用工具不完善。由于更新快，我们的客户端需要随着它的更新来升级才能享受到一些新功能，更新快也意味着很可能在某一阶段会缺乏某个重要功能。另外我们知道MSSQL在DEV/DBA/ADM多个维度都提供了非常好的GUI工具对数据库进行维护。而Mongodb虽然提供了一些程序，但是并不是非常友好。我们的DBA可能会很郁闷，去优化Mongodb的查询。
2）操作事务。Mongodb不支持内建的事务（没有内建事务不意味着完全不能有事务的功能），对于某些应用也就不适合。不过对于大部分的互联网应用来说并不存在这个问题。
在使用Mongodb的过程中主要遇到下面的问题：
1）真正的横向扩展？在使用Memcache的过程中我们已经体会到这种爽了，基本可以无限的增加机器来横向扩展，因为什么，因为我们是通过客户端来决定键值保存在那个实例上，在获取的时候也很明确它在哪个实例上，即使是一次性获取多个键值，也是同样。而对于数据库来说，我们通过各种各样的方式进行了Sharding，不说其它的，在查询的时候我们根据一定的条件获取批量的数据，怎么样去处理？比如我们按照用户ID去分片，而查询根本不在乎用户ID，在乎的是用户的年龄和教育程度，最后按照姓名排序，到哪里去取这些数据？不管是基于客户端还是基于服务端的Sharding都是非常难做的，并且即使有了自动化的Sharding性能不一定能有保障。最简单的是尽量按照功能来分，再下去就是历史数据的概念，真正要做到实时数据分散在各个节点，还是很困难。
2）多线程，多进程。在写入速度达不到预期的情况下我们多开几个线程同时写，或者多开几个Mongodb进程（同一机器），也就是多个数据库实例，然后向不同的实例去写。这样是否能提高性能？很遗憾，非常有限，甚至可以说根本不能提高。为什么使用memcache的时候多开线程可以提高写入速度？那是因为内存数据交换的瓶颈我们没达到，而对于磁盘来说，IO的瓶颈每秒那么几十兆的是很容易达到的，一旦达到这个瓶颈了，无论是开多少个进程都无法提高性能了。还好Mongodb使用内存映射，看到内存使用的多了，其实我对它的信心又多了一点（内存占用多了我觉得CPU更容易让它不闲着），怕就怕某个DB不使用什么内存，看着IO瓶颈到了，内存和CPU还是吃不饱。
Memcache和Mongodb的配合
其实有了Memcache和Mongodb我们甚至可以让80%以上的应用摆脱传统关系型数据库。我能想到它们其实可以互相配合弥补对方的不足：
Memcache适合根据Key保存Value，那么有的时候我们并不知道需要读取哪些Key怎么办呢？我在想是不是可以把Mongodb或说数据库当作一个原始数据，这份原始数据中分为需要查询的字段（索引字段）和普通的数据字段两部分，把大量的非查询字段保存在Memcache中，小粒度保存，在查询的时候我们查询数据库知道要获取哪些数据，一般查询页面也就显示20-100条吧，然后一次性从Memcache中获取这些数据。也就是说，Mongodb的读的压力主要是索引字段，而数据字段只是在缓存失效的时候才有用，使用Memcache挡住大部分实质数据的查询。反过来说，如果我们要清空Memcache中的数据也知道要清空哪些Key。