消息存储设计如下，存于mongodb：
MsgInfo
{
cli_msgid
srv_msgid
msg_order
msg_time
msg_content
all_read_flag
from_uid
group_id
msg_status
}
消息存储方式
消息存储分库，按照群id进行分库，总共分成256个库吧。(对于mongodb就是集合)
消息已读人数单独存档，包含uid数组，这个数组可以删，也可以保留。
群消息已读条数放在会话信息中，消息产生时更新未读条数，设置消息已读时将未读条数清零。
群成员处理
方案一，直接走消息中心，群成员uid列表时实从缓存拉取，之后分别拉列表中的用户在线信息，数据包含在线设备及状态，因为要区分是否推在线通知，是否推push。
方案二，不走消息中心而是走群服务，在群服务做消息流程处理。即独立出群服务，保存群成员列表及所有用户设备在线状态信息，懒加载这些信息到内存。数据有过期时间，比如一小时过期，再配合数据变更通知。如果成员有变更需要通知群服务更新。因为基于懒加载方式，群服务也是无状态，可以随时重启。
群消息处理流程
基于方案二，群消息按照群id进行hash，推送到某一台群服务。
消息去重，
懒加载群成员列表再加载成员在线设备状态信息到内存，
生成msgid，
消息写一次db，
回复ack，
更新所有群成员的会话信息，
为在线设备推通知，
为去重做临时存储。
群服务用户结构设计要满足如下条件：
通过一个群id找到群用户列表，
通过uid找用户设备在线信息，
用户在线设备信息仅存一份，不要冗余，
用户状态变更通知要告知群服务去及时更新，能否做到自动失效或者无需通知？那就每次去拉一波用户在线状态，如此比较耗性能，
多个服务可能都有某个群信息，所以用户设备在线信息变更要广播到所有群服务，能否有设计避免这种广播通知？
万人群的消息通知如何避免或者减少消息风暴？通知合并批量下发，或者设计修改，走异步消息通知队列做缓冲。或者不下发！
