千万级消息设计--初级篇（二）

摘要：需求用户个人消息，平台消息平台给所有人发送消息。原因如果平台用户量较大时，假如万，发一条系统消息，将要给万的人发送一条，就是的消息记录。千万级的数据表，后期通过索引优化，结构优化，业务逻辑优化，避免大量并发查询。

本文都是参加工作的实际情况,希望对大家有所帮助。—— 蚂蚁爬树不怕高，有心学习不怕老。

1.用户个人消息，平台消息（平台给所有人发送消息）。
2.用户未读消息展示，消息列表展示

1.用户信息表users_message

CREATE TABLE `users_message` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(200) DEFAULT NULL,
`content` varchar(4000) DEFAULT NULL,
`uid` int(11) DEFAULT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`msg_type` tinyint(4) DEFAULT "1" COMMENT "用户消息为1, 系统消息为 0",
`is_read` tinyint(4) DEFAULT "0" COMMENT "是否已读0未读1已读",
`ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新时间【不由程序控制，由mysql系统控制】",
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

2.平台信息表sys_message

CREATE TABLE `sys_message` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(20) DEFAULT NULL,
  `content` varchar(500) DEFAULT NULL,
  `create_time` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  `msg_type` tinyint(4) DEFAULT NULL COMMENT "系统消息默认为0",
  `start_time` datetime DEFAULT NULL COMMENT "消息有效时间（开始时间）",
  `end_time` datetime DEFAULT NULL COMMENT "消息失效时间（结束时间）",
  `ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新时间【不由程序控制，由mysql系统控制】",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT="平台的系统消息|通知";

1.用户个人消息:平台中用户的个人普通消息(存储在users_message)。
2.用户系统消息：平台给所有用户发送的 系统消息(存储在users_message)。
3.系统消息：平台给所有用户发送的 系统消息（存储在sys_message）。
4.message:sysmessags:init (原始系统队列) 存放数据库中的sys_message的有效消息（定期需要更新）
5.message:user_sysmessage:compare（用户系统消息队列） 存储 用户与系统消息的关系（建议存储 用户唯一标识和系统消息的唯一标识）对应的时候数据库的关系表

1.用户的消息：当平台给用户发送用户消息，直接在users_message添加一条记录。
2.平台消息：当平台给用户发送系统消息时，在sys_message添加一条系统消息记录。
3.每个平台都会有活跃用户和僵尸用户或不活跃用户。所以系统消息的发送，不会给所有人都发送。
原因：如果平台用户量较大时，假如100万，发一条系统消息，将要给100万的人发送一条，就是100w的消息记录。如果当系统消息堆积到20条，将会2000w用户系统消息，对数据库都是一个不小的压力。当数据量大时，查询，添加等操作都会变的异常慢
4.采取大家常用的处理方式：
1）使用中间表，存储用户的系统消息关系；如果系统消息关系表中没有（系统消息和用户的关系），添加关系，将系统消息插入到用户到用户消息表变为用户系统消息；存在则不做操作。请查看单系统站内信设计概述
2) 使用mongo等，存储用户的消息，也类似上述一样。请自己查阅资料...
我想说说自己的想法:上述的结构等，我在公司都尝试过，但是效果在特殊场合会出现弊端。思路大致为：（数据存储优化 + 业务逻辑优化）

表结构不变，上述中的中间表，我们使用redis替换。

redis缓存记录不存在，插入数据，更新redis缓存。

未读消息个数也使用redis缓存，不需要每次都去查询数据库或mongo(主要取决你的落地数据存储在数据库还是mongo)

消息列表查询，是否每次都查询数据库或mongo,再考虑是否放入redis缓存。（续实践后，再分享给大家）

两张表 users_message 和 sys_message

将sys_message中有效时间内的消息同步或更新到redis列表 message:sysmessags:init (原始系统队列)

        通过初始化自己的项目时，进行同步数据；通过定时程序同步更新数据库和redis中的数据。

当用户在客户端和服务器交互的时候，触发（消息处理）检测用户是否拥有当前有效的系统消息；
存在：不处理消息（可以判断个数）;
不存在：需要添加并且更新数据库或mongo;

        《原始系统队列》与《用户系统消息队列》对比个数，判断是否用户系统消息队列少了部分数据。
        少的部分，需要更新《用户系统消息队列》并且添加新的系统消息到**用户的个人消息表**

消息未读数：使用redis，key - value 的形式存储一个用户未读消息个数数字；维护未读消息，需要在用户更新消息状态和给用户插入消息的时候，需要对未读数进行更新（为了未读数准确，可以进行特殊情况下更新未读数）。

列表暂时查询数据库等数据落地库。

能不使用数据库的就不使用，减少并发情况下，影响数据库的性能。

先做一个简单版，后续慢慢在自己的代码上的优化。

看看自己的情况，觉得选择自己的方案。

千万级的数据表，后期通过索引优化，结构优化，业务逻辑优化，避免大量并发查询。一般都不会出现问题

想详细的解释一下，可是语言真的好难组织哇。写着写着写成最终篇幅了。