高并发写入mysql的设计

最近开发一个项目。客户端每隔10秒提交100行数据给服务端,服务端查重后写入。
客户端约在几万左右,提交数据比较集中,不考虑读数据的问题。
现在的设计是:
数据库按客户端进行分表。每个表的数据量不高。
服务端获得数据后,先插入redis队列,然后在通过定时任务插入数据库。
问题是:
1、服务端提供给客户端的接口,是否能满足几千上万的客户端同时post数据(客户端是10秒提交一次)?
2、将数据首先保存在redis队列中,如果有几十上百万的数据,redis是否稳定?
基本目标是保证服务端能正常提供服务。

———————- 补充内容 ——————————-
项目主要是采集用户的数据。开机就会自动运行。
每次提交100条,10秒提交一次,一般用户每天在10次以内,也就是1000条数据以内。
每条数据包含五六个值对,在100字符以内。
需要保证每天数据的完整性。会出现多个客户端采集同一用户数据的情况,所以需要避免重复。

现在考虑是这样的:
数据表按用户分表。
用户提交的数据按用户先保存在redis队列中,即每个用户每天一个队列,保存到数据库后,删除该队列。

使用MyCat

第一个,有几个考虑

  1. 带宽是否足够

  2. cpu数量,假如4核,php-fpm的数量也是4个的话,每个请求需要50-150ms的处理时间,算下持续时间内处理的请求量大概是多少。

  3. 内存,一个进程10-25M的内存占用。

可以考虑的有:负载均衡,dns轮询。同时注意集群的高可用。

第二个,也有几个考虑

  1. 数据行,一行的长度是?redis对于1k以上都会有性能下降。

  2. 处理速度,队列里面会堆积多少数据,占用内存多大

  3. redis架构,如何保证数据不丢失,如何做高可用

  4. 目前的资源是否允许该方案,是否有其它方案。

并发写不行?那就主主双活,并发写减压50%

  1. 合并插入,不要1条1条插入,比如对应同一张的插入操作,合并1000条插入,这样可以减少交互的次数

  2. 如果这张表只是简单的插入和查询的操作,不需要事务支持的,可以考虑使用MyISAM引擎,相对于InnoDB,在插入时可以获得更高的性能

可以做数据库sharding,一致性hash或者简单的id进行区间hash,应该可以满足吧,如果感觉麻烦,读写分离先看看负载

用队列试试?

看题主说数据产生相对集中…那么可以考虑下利用队列任务将集中的任务时段稍微拉宽一点….尽量平滑写入…需要在写入读取延迟和平滑处理时长之间找一个合理的平衡点即可….要是实在是没得让步余地就其实前面说的高端路子…另外不想折腾数据库的话也可以试试先写到dump文件…另一个配套导入….不知道这算不算野路子….

-1. 一次提交100条,10秒来处理显然是比较急的,我假定你的数据是允许部分丢失的前提下,可以考虑在客户端做缓存(把数据缓存在客户端,其实是一种冒险的做法),比如我200条,20秒提交一次。
-2. 服务端可以采用任务队列,减少服务器的阻塞,从而提高并发。(10秒提交一次,很容易出现高并发)

-3. 另外要考虑数据是否经常进行读写,否则建议才有ehcache,集群同步带来额外的开支。

-4. 这么特殊的业务肯定不要和其他业务公用服务器了.

-5. 后面关于怎么分表的,这个得看你的业务了.

  • php用自带mail函数发送邮件配置
  • 有什麼好的內容管理系統推荐
  • 在js的正则里面能引用正则本身的变量吗?
  • 两个文章,如何知道另一个人或多个在编辑?
  • redis分好库之后怎么才能看每个库的大小呢?
  • PHP存进redis的session数据为什么是这个格式的?我如何解析呢?aa|s:3:\"aaa\"
  • 还是这个问题 : Provisional headers are shown
  • mysql普通索引效率
  • php print_r打印是一片空白
  • 闹鬼!php字符串数组交叉
  • thinkphp M数据库无法切换