读《不做技术的奴隶》有感

今天看了《不做技术的奴隶》这个帖子，挺有意思的，大家对ORM、SQL Map、Cache等等展开了激烈的讨论，看到了不同观点，不同的经验，不过我到觉得，大家不用争论某个框架的优劣，因为框架不能决定设计，设计是由需求决定的。

看完了帖子，我到想说说自己的经验，包括以前的项目和天乙社区的设计。

我曾经在网易工作，在网易的锻炼使我在互联网应用方面认识大大的提高，我在网易的时候参与网易俱乐部的项目，这个项目现在已经停止运营，这个项目基本上就是电子小组的功能，也就类似与现在的圈子，就是个人可以创建俱乐部，有感兴趣的人加入，俱乐部主要包括论坛、相册、文件夹等等功能，那么在网易海量用户基础上怎样取得比较好的性能呢？网易采取的数据库设计原则是粗粒度的，冗余的做法，要求程序员尽量减少数据库查询，能查1次SQL解决的绝不查2次，当时ORM框架还没有流行起来，程序框架就是采用JSP+JDBC，数据库采用Oracle，无论从当时还是现在的眼光看，这个系统的设计都称不上优雅，甚至有些丑陋，但确支撑了百万级数据。

具体举例，我们还是拿论坛来说，帖子列表，除了帖子标题、时间这些必要元素之外，列表上要显示发帖用户昵称、最后回复人等等，如果采用细粒度的方式，就要出现n+1的查询问题，那么我们索性就把这些字段写入帖子表，从实践来看，效率是不错的，当然大家提出可以通过缓存来解决细粒度带来的效率问题，这个我等会专门来说缓存的问题。

在进入列表时，我们是不需要看到帖子正文的，那么帖子正文该如何存放能，是与帖子表建立one-to-one的关联表，还是用什么其他的方法呢，网易采用了文件的方式，帖子正文是放在文件系统里的，通过NFS可以让多个服务器调用，文件的存放是多目录有规则的，虽然文件的方式在迁移的时候会比较不便，但一个系统会有几次迁移的机会呢？还有，NFS在性能上可能会有问题，但现在共享存储的技术已经很成熟，如果需要效率更高的文件存储，可以购买现成的设备或解决方案，一般来说，在7、8台服务器时，NFS够用了。

接下来我们说说缓存的问题，在细粒度条件下，缓存确实能解决不少效率的问题，但是缓存能提高效率，是建立在高命中率的基础上，我在网易的项目没有使用任何缓存，因为数据量实在太大，用户大约300多万，有几万个俱乐部，每个俱乐部都有一定数量的帖子，这些帖子的存取，几乎是完全随机，缓存起不到作用，如果要使用缓存，这个缓存必须足够的大。我觉得缓存应该使用在频繁访问的数据上，在天乙社区里，版区信息就非常适合缓存，因为版区数据不会多，一个论坛如果有几百个版区，已经相当庞大了，大多数论坛不会超过20个。在进入帖子列表时，显示版区信息，这些信息都从缓存中出来。

在天乙社区中，第一次进入版区列表时需要4个SQL查询，2个更新在线表，在线列表中显示用户显在某个版区（这个功能要不是很多人需要，我真的不愿意加上），另外2个是对帖子表做一个count，以便分页，另外一个就是查询列表了，如果用户还在这个版区，再刷新这个版区列表，就只需要2个SQL了，不需要再做在线表的更新，如果用户进入第二页，则只需要一个SQL了，应为我会把count数据带入url，不需要在做count。

互联网的应用对数据的实效性和完整性要求并不高，比如，在帖子列表的字段里加入用户昵称，而后来用户修改了昵称，修改就修改了，以前发的帖子里就是以前的昵称，这不会造成什么严重的影响，所以采用冗余的方法可以比较好的提高效率。

总的来说，采用何种设计原则还是要看需求，对于电子商务这样数据实效性和精度要求高的项目，则粗粒度就不太适合，比如人家商品名称变了，订单里的、收藏里的等等地方还是要做关联查询的，我以前看Robbin的一个帖子，上面讲web server可以横向扩展，中间采用memcache，后端数据库，这个方案我比较认可，但也要考虑现实部署的方便性，比如总体需要20台服务器，那怎样租用机柜等等问题也还是考虑的。