关于互联网业务在数据库方面的一些…

今天有幸听公司两位老鸟讨论互联网业务在数据库方面的一些经验，本文只是对他们讨论的一个记录与总结。

互联网业务大体可以分为两种：新兴的互联网业务，如网游（QQ农场）， 和传统的互联网业务，如通信计费（移动的计费）。

对于新兴的互联网业务而言，绝大多数情况下满足如下特点：

1.事务性不强

2.可扩展性要求高

3.每次请求的数据量不大，但总体访问量巨大

4.对于应用层的设计而言，常用的设计方式是 一条sql语句对应一张表，而且绝大多数sql语句都是简单的单表操作的语句。

5.对于负载方面的设计，通用的方式是cache+sharding （每个表最多10几万的数据量）, 这就对前期设计与对应用负载的预估有很高的要求。（主要为了优化查询）

6. 读写操作的比例一般在10：1， 热点数据的比例大约是30%

拿qq农场为例， 每次操作所提交的数据其实非常的少，无非就是一些状态变量值的改变，但短时间内可能会有非常大量的提交。例如一个用户的浇水，施肥，除虫，收获。。。。。。 等等 一系列的操作会导致一连串的鼠标点击，从而1秒内产生一连串的修改请求，这些请求数再乘上巨大的用户数，总的请求数是很巨大的。 把这些请求直接送到后台DB那里显然是不合理的，现在服务器支持的I/O写操作每秒最多也就一两百次那样。 所以需要提前处理一下这些修改请求，在应用层先将这些请求合并一次，在后台可能还需要在合并一次，最后才真正提交到DB上。 这样做导致的结果就是不能保证绝对的事务性。不过对于农村那样的网游，多摘一颗菜，少摘一个菜，本身没太大关系。所以牺牲一些事务性来保证性能。

对于传统的互联网业务而言，主要有一下不同：

1. 有很强的事务性要求

2. 单个用户在短时间内的更新的量和次数都较少

3. 一般的负载策略是分区 (这块有点记的不清了， 应该是在不同区域架设相同或类似的服务器，然后负载均衡吧)

后记：据说这次双11淘宝上出现的用户投诉说自己的订单被莫名退单了，就是因为后台的数据服务器承受不住压力出现错误（数据丢失，或本来就30个库存的接受了50个预订之类的）。 然后淘宝的人把这些错误的订单就直接弄成退单了。。。。。。 （这只是听说）