数据共享好文

  [传统的解决方案]

    对于这类数据的存储，传统的作法是保存在数据库中，前面搭上缓存，用用户的ID做为KEY，把特权数据作为VALUE保存。读请求直接从缓存中读取，如果缓存中没有时则从数据库中查询，而写请求则直接落到数据库中。这种方法基本可以解决单个查询的情况，但对于批量查询，开销还是比较大的。假设缓存的命中率是95%（这个命中率相当高了），同时假设每个用户平均有20个好友的话，每次批量查询就有可能有一个好友的数据缓存中没有，需要到数据库查询，而查询数据库，因为涉及到磁盘IO操作，所以速度与访问内存相比是相当慢的。

 

   [采用文件映射的解决方案]

   下面介绍另一种解决方案给大家，那就是使用共享内存或文件映射的方式进行保存（重要不可丢失的数据，采用文件映射+DB的方式，而访问量高但是可丢的数据可以采用共享内存的方式）。

    以上面的场景为例，我们可以定义下面的结构体表示用户的记录：

   struct

   {

        uint32_t id;

        uint8_t info;

   } stUserInfo;

   假设一个网站有1亿的注册用户，那么把所有用户的信息保存在一个文件中，需要10KW*5字节的空间，另一种方式是直接用用户的id做为下标，这样1亿用户的信息可以完全保存在一个数组中，uint8_t user_info[1000 * 1000 *100， 存储空间节省为原来的1/5。更进一步，我们可以把这个数组mmap到一个文件中，这样，每次查询的时候，无论是单查还是批量查询，其实都是在查询共享内存，通过下标直接索引的方式，效率非常高，由于写操作比较少，所以刷文件的次数也很少，对磁盘IO的开销比较低； 另外，如果写操作相对量比较大的话，为了避免很少小包的请求，可以在前面搭一层机器用于合并写请求，把若干次单写操作合并为一次批量写。

   [面临的一些其它问题]

   这种文件映射存储用户数据的方式，可以广泛应用于现在的互联网应用中。这种方案的思想是，尽可能把所有用户数据粒度细化，保存在一台机器中，由于现在64位机器，最大可提供的内存到了32G，给用户进程使用的空间还是很大的，基本可以满足需求。当然，这里也面临两个问题：

   1.单个用户的数据量大，一台机器存储不够

   2.单个用户的数据量小，但用户总量很大，一台机器存储不够

   问题1：以把其中的数据进行细分，把共性的数据提供出来，进行纵向拆分，把类型相同的数据尽可能部署到一台机器上。比如用户信息中除了特权信息还有等级信息，可以把特权信息单独放到一台机器上，等级信息放到另一台机器上，如果说数据无法拆分，就可以参考问题2的解决方案。

   问题2：根据用户的ID横向拆分，比如ID[1， 5KW]的用户在一台机器上，ID[5KW+1，10KW]的用户在另一台机器上，因为是需要下标访问的，因此可以给每个进程定一个起始偏移量，比如对于ID=5KW+1的用户，它的下标就是5KW+1 - 起始偏移量(5KW+1) = 0，也就是保存在数组的第一个位置上，这样，随着用户量的上升，只需要扩容就可以解决。

   [总结]

   这种文件映射的思想可以广泛应用于互联网，特别上SNS应用中，不仅效果好，也可以大大节省了服务器成本，更多的应用场景值得我们继续挖掘。