请教一下高频率读写的情况下,mysql应该如何优化?

Tek_Eternal 发布于 2014/08/27 09:07
阅读 618
收藏 2

需求是这样的:目前手头项目有个帮用户发送点对点短信的功能,用户一次可能发送几千或上万条短信,服务端接受用户的发送任务后,使用一个待发池慢慢帮用户发。但是页面上用户需要能实时查询短信的发送任务的情况:比如本次发送任务的成功数,失败数,发送任务的状态(全部发完,或正在发送中), 任务中每条短信当前状态(待发送,发送成功,发送失败)等。每条短信发出后,外系统会异步地将状态报告回来 

目前数据库结构是这样的:

数据库是Mysql,存储引擎Innodb,除了主键外键外还没有加其他索引

涉及到几张表:

  1. 短信发送任务表:记录用户提交的发送任务,字段有:短信内容,发送数,成功数失败数(明细表状态变更后要重新计算)整个任务的状态,短信内容
  2. 短信明细表:记录具体每条短信的发送情况,字段有: 所属短信任务id(外键关联到任务表),接收方号码,发送状态(外系统状态报告过来后需要实时更新)
  3. 待发池表:结构与短信明细表类似,用来储存发送队列,调用外系统接口发送后,删除记录。 


现在遇到的问题是:如果将待发池发送量调大,短信明细表 跟 短信发送任务表 读写会非常频繁(特别是发送任务表里的成功数与失败数,量大了经常因为行锁而访问不了,或者最后数量上统计出错,成功数+失败数!=发送数)

我想问下:这种情况下,该对数据库如何优化?加索引?读写分离?还是直接把读写频繁这些字段搬出来放到memcache之类的缓存里,再定时持久化回mysql?

加载中
0
Arrowing
Arrowing

1、数据放进缓存里,到达一定条件时存储到mysql一次,比如一万条信息的发送记录

2、采用SSD硬盘

3、发送列表不要实时更新

4、如果插入频繁还是不要加其他索引的好,毕竟几千条数据,人家只看总结,不看具体

Arrowing
Arrowing
回复 @Tek_Eternal : 我说的第一和第三条应该是一个道理的,就是数据库有数据才查得到!任务没完全完成重发干什么?完成了自然可以看到了,其实第一条和redis异步同步差不多,由于你们使用的是mysql,redis异步可能会影响到性能,所以放缓存里应该会好点,但需要自己保障数据安全。
Tek_Eternal
Tek_Eternal
谢谢! 2 用ssd硬盘没办法,因为服务器不是我们管的 3 发送列表不要实时更新也没办法,用户发送完就想关注发送情况 4 除了成功数失败数数之外,用户还想看具体某一条短信发送状态,针对某一条短信进行重发。 所以是不是只剩下用缓存这种方法改造最快了? = =
0
黄开源中国
黄开源中国
考虑使用memcache,redis这种来存。再异步持久化入库。。性能提高非常明显。
0
pseudo
pseudo
内存数据库
返回顶部
顶部