本发明主要涉及用户消息的后台处理技术，尤其涉及一种后台解决用户消息处理和存储的方法及系统装置。
背景技术：
目前很多涉及用户的后台系统，无法避免的都需要处理用户相关的消息，比如：系统消息、用户购买产品后产品更新消息，用户关注大v后大v动态消息等等。
传统的方案就是一条消息有n个接收者，就存n条数据，那么问题来了，如果用户量比较大，那么一条消息会产生几十万条数据，而且数据重复度很高。而且取指定用户的消息时，由于消息量级太大，导致消息越多，性能呈指数级下降，耗时呈指数级上升。里面涉及两个核心问题：
1、消息存储问题：一条用户消息（全员推送/分组推送/定向推送）传统的方案就是一条消息有多个接收方，就存储多条数据。
2、获取用户消息的耗时问题，随着消息的增加，数据量增长，耗时会越来越长。
技术实现要素：
为解决上述背景技术中存在的技术问题，本发明采用mysql，共享内存和redis技术，利用其不同的存储性质针对性的存储相应的用户消息及其内容，提高运行速度。使用定期结算的方法解决了消息的存储和分发的问题，总体上提升了整个后台服务的效率及稳定。其具体的技术方案如下：
第一方面，一种后台处理和存储用户消息的方法，所述方法包括如下步骤：
（1）启动程序，运行后台服务器及周期处理模块；所述周期处理模块以n个时间粒度为周期对所述后台服务器获取的未处理的用户消息执行消息处理操作；
（2）所述后台服务器调用所述存储模块一，将所述存储模块一中自上次程序关闭时间之前h个时间粒度范围内的用户消息存储于存储模块二中；所述用户消息包括已处理的用户消息或/和未处理的用户消息；所述用户消息包括但不限于消息id、消息内容、发布时间、用户id集合；所述存储模块二只存储最近h个时间粒度范围的数据；
（3）所述后台服务器获取未处理的用户消息存储于存储模块二及存储模块一；
（4）所述后台服务器提取所述存储模块一中已处理的用户消息组建用户消息数组m1；所述用户消息数组m1包括已处理的用户消息的消息id及对应的用户id集合；
（5）所述后台服务器根据存储模块二中h个时间粒度范围内的用户消息组建用户消息数组m2；所述用户消息数组m2包括已处理的用户消息或/和未处理的用户消息的消息id及对应的用户id集合；
（6）所述后台服务器接收用户的获取请求，所述后台服务器接执行用户消息数组m1与用户消息数组m2的合并去重操作，生成用户消息索引；所述用户消息索引包括但不限于用户id及对应的已处理的用户消息或/和未处理的用户消息的消息id；
（7）所述后台服务器获取所述用户消息索引，根据所述用户索引的用户id及对应的已处理的用户消息或/和未处理的用户消息的消息id，从存储模块中提取所述消息id对应的消息内容呈现给对应用户id。
结合第一方面，在第一方面的第一种可能的实现方式中，所述存储模块一包括mysql数据库、redis缓存；所述存储模块二为共享内存，所述步骤（2）还包括：
所述后台服务器提取存储模块一的mysql数据库中已处理的用户消息存储至redis缓存；所述mysql数据库存储所有后台服务器推送的用户消息，包括已处理的用户消息或/和未处理的用户消息；所述redis缓存存储mysql数据库中所述已处理的用户消息对应的包括但不限于消息id、消息内容及步骤（6）中生成的所述用户消息索引。
结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述后台服务器获取未处理的用户消息时，赋予所述用户消息send_status参数，且设置所述send_status=0；所述send_status参数反应n个时间粒度内后台服务器推送的用户消息是否进行消息处理操作，若send_status=0，则为未处理；若send_status=1，则为已处理；若send_status=2，则为处理不成功。一般情况下send_status都能置为1，一旦置为2则说明消息处理模块出现问题，则系统会自动发出告警，提示维护人员进行故障排查。
结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述周期处理模块执行消息处理操作后，所述后台服务器依据消息处理结果修改mysql数据库和共享内存中未处理的用户消息的send_status参数值为1或2。
结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述后台服务器提取mysql数据库中所述send_status参数值为1的已处理的用户消息存储至redis缓存。
结合第一方面的第三种和第四种可能的实现方式，在第一方面的第二种可能的实现方式中，所述步骤（8）包括：所述后台服务器获取所述用户消息索引，根据所述用户的获取请求，获取该用户的用户id，调用所述用户消息索引根据所述用户id获取对应的的已处理的用户消息或/和未处理的用户消息的消息id；根据所述已处理的用户消息或/和未处理的用户消息的消息id提取所述消息id对应的消息内容呈现给对应用户。
结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，步骤（6）中所述后台服务器接收用户的获取请求后，实施所述步骤（4）和步骤（5）组建所述用户消息数组m1和m2，执行合并去重操作，生成用户消息索引。
结合第一方面的第六种可能的实现方式，在第一方面的第七种可能的实现方式中，所述时间粒度单位为小时，所述h=2n。
第二方面，一种后台处理和存储用户消息的系统，所述系统包括：
后台服务器，用于获取未处理的用户消息并存储于存储模块内的不同存储装置中，赋予未处理用户消息send_status参数，依据消息处理结果修改send_status参数，生成相应的用户消息数组m1及m2并进行合并去重操作，生成用户消息索引，根据所述消息索引从相应存储装置拉取具体消息内容呈现给对应用户；
存储模块，用于存储用户消息，包括存储模块一、存储模块二；所述存储模块一包括mysql数据库、redis缓存，所述存储模块二为共享内存；其中：
mysql数据库用于存储后台服务器推送的所有用户消息，供后台服务器调用数据；
redis缓存用于存储mysql数据库内已处理的用户消息的消息id和对应的消息内容，以及所述用户消息索引，供后台服务器调用数据；
共享内存用于系统启动后首次存储mysql数据库内最新的h个时间粒度范围的用户消息，且后续后台服务器每获取一次未处理的用户消息均分发至所述共享内存，所述共享内存只存储最近h个时间粒度范围内的数据；
周期处理模块，自系统启动后执行一次消息处理操作，对mysql数据库和共享内存中未处理用户消息执行消息处理操作，并根据操作结果供后台服务器修改所述send_status参数，参数修改后将mysql数据库中已处理的消息存储至redis缓存，对redis进行更新；所述周期处理模块每隔n个时间粒度执行一次消息处理操作。
第三方面，一种后台处理和存储用户消息的系统装置，所述装置包括：
后台服务器，用于获取未处理的用户消息并存储于存储模块内的不同存储装置中，赋予未处理用户消息send_status参数，依据消息处理结果修改send_status参数，生成相应的用户消息数组m1及m2并进行合并去重操作，生成用户消息索引，根据所述消息索引从相应存储装置拉取具体消息内容呈现给对应用户；
存储模块，用于存储用户消息，包括存储模块一、存储模块二；所述存储模块一包括mysql数据库、redis缓存，所述存储模块二为共享内存；其中：
mysql数据库用于存储后台服务器推送的所有用户消息，供后台服务器调用数据；
redis缓存用于存储mysql数据库内已处理的用户消息的消息id和对应的消息内容，以及所述用户消息索引，供后台服务器调用数据；
共享内存用于系统启动后首次存储mysql数据库内最新的h个时间粒度范围的用户消息，且后续后台服务器每获取一次未处理的用户消息均分发至所述共享内存，所述共享内存只存储最近h个时间粒度范围内的数据；
周期处理模块，自系统启动后执行一次消息处理操作，对mysql数据库和共享内存中未处理用户消息执行消息处理操作，并根据操作结果供后台服务器修改所述send_status参数，参数修改后将mysql数据库中已处理的消息存储至redis缓存，对redis进行更新；所述周期处理模块每隔n个时间粒度执行一次消息处理操作；
还包括处理器、存储器、总线，所述处理器同存储器通过总线进行数据连接，所述存储器内存有多条操作指令，所述处理器加载所述多条操作指令并执行，实现上述第一方面及第一方面的多种可能的实现方式中所述的方法。
有益效果：
本发明主要的创新点如下：
1、对于一条消息有n个接收者的情况，只需要存一条消息。而传统的方案就是一条消息有n个接收者，就存n条数据。
2、以用户为维度建立消息索引，索引只存消息类型和消息id，不存具体的消息体。
本方案采用mysql，共享内存和redis技术，使用定期结算的方法解决了消息的存储和分发的问题，此种方案将数据平均存储量减少到原来的万分之一，前端获取用户消息的访问耗时成倍降低。
附图说明
图1为本发明的实施例一的方法流程图；
图2为本发明的mysql表属性图；
图3为本发明的局部时间轴图；
图4为本发明的系统结构图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例一：
本发明采用mysql，共享内存和redis技术，利用其不同的存储性质针对性的存储相应的用户消息及其内容，提高运行速度。使用定期结算的方法解决了消息的存储和分发的问题，总体上提升了整个后台服务的效率及稳定。如图1所示其方法的具体步骤如下：
（1）启动程序，运行后台服务器及周期处理模块；所述周期处理模块以n个小时为周期对所述后台服务器获取的未处理的用户消息执行消息处理操作，其操作的处理结果供后台服务器调用对所述send_status值进行修改，并且依据修改后的send_status值，从所述mysql数据库中提取已处理的消息存储至redis缓存中。也就是说所述周期处理模块每隔n个小时更新一次所述redis缓存。其中，所述redis缓存存储mysql数据库中已处理的用户消息对应的消息id、消息内容，以及步骤（6）中生成的所述用户消息索引。
（2）启动程序后，系统需要进行一次准备工作，首先周期处理模块会执行一次消息处理操作，处理上次系统关闭时未处理的用户消息，并且更新一次redis缓存。同时，所述后台服务器调用存储模块一中的mysql数据库，将所述mysql数据库中自上次程序关闭时间为止向前h个时间粒度范围内的用户消息存储于存储模块二（即共享内存）中。
所述用户消息包括已处理的用户消息或/和未处理的用户消息；所述用户消息主要包括消息id、消息内容、发布时间、用户id集合，一条消息可能需要发给多个用户，所以每个消息id可能对应多个用户id，每个用户id也可能对应有多个消息id。
所述共享内存只存储h个时间粒度范围的数据，每当后台服务器获取到未处理的消息发送至共享内存中，其共享内存就已此条消息的存入时间开始往前保存h个小时范围内的数据，超出其h个小时范围的数据就自动抹除。
（3）所述后台服务器获取未处理的用户消息存储于mysql数据库及共享内存中，所述未处理用户消息包括消息类别、消息id、消息内容、发布时间、待处理用户id集合。其中，后台服务器获取未处理的用户消息后，可同时分发至mysql数据库及共享内存，也可分别按顺序发送，亦或先发送至mysql数据库及共享内存中的任意一个，再由此存储设备发送至另外一个存储设备，其发送顺序对本发明而言并无影响。
所述后台服务器获取未处理的用户消息时，赋予所述未处理用户消息send_status参数，且设置所述send_status=0；所述send_status参数反应n个时间粒度内所述后台服务器推送的未处理用户消息是否进行消息处理操作，若send_status=0，则为未处理；若send_status=1，则为已处理；若send_status=2，则为处理不成功。
一般情况下，通过所述周期处理模块执行消息操作处理后，其send_status值均会置为1，只有极少数情况会置为2,。若置为2则说明消息处理操作出现了错误，需要对其进行维护，所述周期处理模块会发出告警。
其中，所述mysql数据库存储所有后台服务器推送的用户消息，包括已处理的用户消息及未处理的用户消息，并在所述周期处理模块每隔n个小时执行一次消息处理后，将mysql数据库中存储的已处理消息发送至redis缓存中，更新所述redis缓存。所述mysql数据库中mysql表的具体属性如图2所示。
所述后台服务器提取mysql数据库中每条用户消息对应的消息id、消息内容，存储至redis缓存。
redis中的数据结构如下：
消息体(简称d1)
key:“msg|[messageid]”;//其中[messageid]为消息id
value:{
id:消息id，
type：消息类型
content：内容
updatetime：发布时间
}
共享内存中消息的数据格式如下：
{
list:[
{
id:消息id，
type：消息类型
content：内容
update_time：发布时间
to_users：待发送的用户id集合，以|分割
}
]
}
（4）所述后台服务器提取redis缓存中已处理的用户消息组建用户消息数组m1；所述用户消息数组m1包括已执行消息处理操作的用户消息的消息id及对应的用户id集合。所述用户消息数组m1中的消息id按照用户消息的发布时间顺序排列。如图3所示，当系统运行时间虚线在n个小时周期中时，m1仅包含所述系统运行时间虚线左侧的上一次周期处理模块执行消息处理操作后的已处理用户消息。
（5）所述后台服务器根据存储模块二中h个时间粒度范围内的用户消息组建用户消息数组m2；所述用户消息数组m2包括已处理的用户消息或/和未处理的用户消息的消息id及对应的用户id集合。
在一个周期的n个小时内，后台服务器可能会多次接收到未处理的用户消息，作为一种可能方式，后台服务器每次接收未处理的用户消息后，都从mysql数据库提取最新的h个小时的已处理的用户消息或/和未处理的用户消息存储于共享内存中。
如图3所示，当系统运行时间虚线在n个小时周期中时，共享内存中包含从所述系统运行时间虚线往左的h个小时内的用户消息，所述h=2n。包括上一次周期处理模块执行消息处理操作时间轴的左侧同所述h个小时重合处的已处理用户消息，以及上两次周期处理模块执行消息处理操作时间轴的右侧的未处理的用户消息。
（6）当用户提出获取其用户id下的用户消息（包括已处理的用户消息或/和未处理的用户消息）的请求时，所述后台服务器接收用户的获取请求，所述后台服务器接执行用户消息数组m1与用户消息数组m2的合并去重操作，生成用户消息索引存储于redis缓存中。
所述用户消息索引包括用户id及对应的已处理的用户消息或/和未处理的用户消息的消息id。所述用户消息索引中的消息id按照用户消息的发布时间顺序排列。
本方法中，可以在获取用户请求前组建所述用户消息组m1和m2，待获取用户请求后再执行合并去重操作，也可以在获取用户请求后组建所述用户消息组m1和m2再执行合并去重操作，其组建的顺序对本发明而言并无区别。
（7）所述后台服务器获取所述用户消息索引，根据所述用户消息索引的用户id及对应的已执行消息处理操作的用户消息的消息id，从redis缓存中提取所述消息id对应的消息内容呈现给对应用户id。用户可以在客户端查看后台服务器发送的所有按用户消息的发布时间顺序排列的用户消息。
本方案采用mysql，共享内存和redis技术，利用mysql数据库存储最原始的用户消息，包括已处理和未处理的用户消息，将具体的消息内容存储于redis缓存中，共享内存中仅存储从mysql提取的最新h个小时内用户消息。在进行去重操作时，可以快速的读取共享内存中用户消息组建用户消息数组m1，而不用去像传统的通过mysql数据库提取，大大提高了读取速度。并且生成的用户消息索引只需根据消息id从redis缓存中提取具体消息内容，也无需经过mysql数据库，大大提高了读取速度。
其次，使用定期结算的方法解决了消息的存储和分发的问题，所述周期处理模块每隔n个小时执行一次消息处理操作，批量处理多条用户消息，而不用每来一条用户消息都要进行处理。此种方案将数据平均存储量减少到原来的万分之一，前端获取用户消息的访问耗时成倍降低。
实施例二：
所述后台服务器推送未处理用户消息至mysql数据库后，所述后台服务器执行一次提取，提取所述mysql数据库中从最近一次用户消息发布时间往前h=2n个小时范围内的已执行消息处理操作的用户消息和未处理的用户消息，单独存储于共享内存。在一个周期的n个小时内，后台服务器可能会多次接收到未处理的用户消息，每次接收都会从mysql数据库提取最新的2n个小时的用户消息存储于共享内存中。
共享内存中存储2n个小时的用户消息还有一个作用是数据备份。理论上只需要存n小时的消息，考虑到有可能上次周期性处理过程中服务挂掉，那么如果只存n个小时的消息，可能存在系统重启后从mysql数据库恢复n个小时的数据可能遗漏一些挂掉前的共享内存中的消息，故此处存最近2n小时的数据比较可靠。
实施例三：
在上述整个步骤中，消息id的传输中附带有对应的用户消息的消息类别，且每个用户id根据其开展的业务也会有不同的消息类别，其用户消息索引的索引结构为用户id→至少一个消息类别→消息id。通过上述方法通过所述用户消息索引不仅可以查看按用户消息的发布时间顺序排列的所有用户消息，还可以根据消息类别选取某一类别中的按用户消息的发布时间顺序排列的所有用户消息。为用户提供更精确的消息查询功能。
实施例四：
基于上述方法，本发明提供了一种后台处理和存储用户消息的系统，如图所示所述系统包括：
后台服务器，用于获取未处理的用户消息并存储于存储模块内的不同存储装置中，赋予未处理用户消息send_status参数，依据消息处理结果修改send_status参数，生成相应的用户消息数组m1及m2并进行合并去重操作，生成用户消息索引，根据所述消息索引从相应存储装置拉取具体消息内容呈现给对应用户；
存储模块，用于存储用户消息，包括存储模块一、存储模块二；所述存储模块一包括mysql数据库、redis缓存，所述存储模块二为共享内存；其中：
mysql数据库用于存储后台服务器推送的所有用户消息，供后台服务器调用数据；
redis缓存用于存储mysql数据库内已处理的用户消息的消息id和对应的消息内容，以及所述用户消息索引，供后台服务器调用数据；
共享内存用于系统启动后首次存储mysql数据库内最新的h个时间粒度范围的用户消息，且后续后台服务器每获取一次未处理的用户消息均分发至所述共享内存，所述共享内存只存储最近h个时间粒度范围内的数据；
周期处理模块，自系统启动后执行一次消息处理操作，对mysql数据库和共享内存中未处理用户消息执行消息处理操作，并根据操作结果供后台服务器修改所述send_status参数，参数修改后将mysql数据库中已处理的消息存储至redis缓存，对redis进行更新；所述周期处理模块每隔n个时间粒度执行一次消息处理操作。
基于上述系统，本发明还提供了一种后台处理和存储用户消息的系统装置，所述系统装置包括：
后台服务器，用于获取未处理的用户消息并存储于存储模块内的不同存储装置中，赋予未处理用户消息send_status参数，依据消息处理结果修改send_status参数，生成相应的用户消息数组m1及m2并进行合并去重操作，生成用户消息索引，根据所述消息索引从相应存储装置拉取具体消息内容呈现给对应用户；
存储模块，用于存储用户消息，包括存储模块一、存储模块二；所述存储模块一包括mysql数据库、redis缓存，所述存储模块二为共享内存；其中：
mysql数据库用于存储后台服务器推送的所有用户消息，供后台服务器调用数据；
redis缓存用于存储mysql数据库内已处理的用户消息的消息id和对应的消息内容，以及所述用户消息索引，供后台服务器调用数据；
共享内存用于系统启动后首次存储mysql数据库内最新的h个时间粒度范围的用户消息，且后续后台服务器每获取一次未处理的用户消息均分发至所述共享内存，所述共享内存只存储最近h个时间粒度范围内的数据；
周期处理模块，自系统启动后执行一次消息处理操作，对mysql数据库和共享内存中未处理用户消息执行消息处理操作，并根据操作结果供后台服务器修改所述send_status参数，参数修改后将mysql数据库中已处理的消息存储至redis缓存，对redis进行更新；所述周期处理模块每隔n个时间粒度执行一次消息处理操作。
还包括处理器、存储器、总线，所述处理器同存储器通过总线进行数据连接，所述存储器内存有多条操作指令，所述处理器加载所述多条操作指令并执行，实现上述第一方面及第一方面的第一至第八种情况中所述的方法。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所描述的装置实施例仅仅是示意性的，可以是设计成一体设备，也可以是组合成一套设备，也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件和必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。