求问每隔五秒有 4k 用户轮询该用什么配置的服务器

[qq915458022]

每个用户请求就会 UPDATE 一下 mysql 数据库。。 如果只有一台服务器，求问各位 V 友至少要什么配置

[billlee]

如果均匀分布的，那么 IOPS 是 800 s^-1, 如果要持久化到磁盘就必须要用 SSD.
如果可以放弃持久性要求，可以用 redis 或者把 innodb_flush_log_at_trx_commit 设置成 0.

[qq915458022]

@billlee 我先上个 ssd 试试吧
实在不行就准备弄分布式了🌚

[ipconfiger]

@qq915458022 如果一直是这个频度的话, 基本上压力都是在数据库上了, 前端加什么都不好使, 先上个阿里云的 RDS 自己测一下 TPS, 能超过 1000 就 ok, 可以从最小规格的开始实验.
我在网上找到一个评测文章你可以参考一下:
http://chuansong.me/n/2057150

另外, 如果全是 update, 而且 MySQL 测试出来不 满足 1000 的 TPS, 比如只有 200(原来年幼无知的时候在阿里云的最挫的 VPS 上本机装 mysql 测出来的结果). 那么可以用 redis 来做个对列, 如果光用对列是没用的, 因为写入数据库的频度始终比来数据的小, 所以对列会一直堆积耗光内存, 我原来做的对列是可以合并 update 请求的, 比如用 update 一个计数作为例子, 如果发现前面有未执行的 update 的值, 就把几次请求合并成一次数据库写入, 这样子数据库就不需要那么高的 TPS 了.

[qq915458022]

@ipconfiger 因为数据是实时的而且要能在后台实时反应出来。。如果用内存积压的方法还要再从内存中读出来，感觉很麻烦。

目前配置可以往上堆，但是日后用户可能还要增长几倍（现在是测试小组 4000 人🌚），又只有一台服务器，所以有点伤感😂

[qq915458022]

@ipconfiger 其实也可以考虑合并呢。。隔 5s update 一次也会缓解很多，而且这下只考内存了

[billlee]

@ipconfiger 其实不需要在逻辑上对 UPDATE 请求做合并，只要把一串 UPDATE 放到一个 transaction 里去执行，速度就会快很多了吧，瓶颈一般是每次提交事务时 flush redo log 产生的 IO 操作。

[fuxkcsdn]

1 ， SELECT * FROM userstatus 改掉，只取要用到的字段，还有，如果 phone 字段不是主键或者没有唯一索引的话， SQL 语句后面加上 LIMIT 1 （除非你的业务逻辑存在取多条记录的可能）
2 ， UPDATE 语句打印 explain 出来看看（需要 MySQL 5.6 以上），可能的话把 UPDATE 语句完整的贴出来

BTW ，可以 isset($_GET['phone'], $_GET['sim'], $_GET['group']) && is_numeric($_GET['phone']) && is_numeric($_GET['sim']) && ....

[billwang]

一般来说，试一下，扛得住就行，看不住再升级。：）

[ipconfiger]

@billlee 因为逻辑上来说只需要同步最终状态所以合并处理是最优的, 这个方案是原来做游戏服务器的时候用的, 主要的数据操作都在内存完成, 往数据库存只是为了持久化, 那么其实只需要持久化最终状态即可

[kaneg]

看了楼主发的代码截图，其实就是在数据库中持久化以 phone 为 key ， owner 和 sim 为 value 的一个 map ，而这个 map 的大小为 4k 。所以最简单的办法就是在内存中保持这个 map ，新来的请求就只是更新这个 map 。而这个 map 多长时间刷新到数据库就看你的数据库的压力承受能力。

如果要读取用户的状态，只要先在内存 map 中查，能查到这就是最新状态，查不到再在数据库中读取。

这样下来，数据库的 IO 压力是可调整的。而能不能抗得住 5 秒内 4k 的 http 请求主要看服务器的 CPU 了。

[quericy]

17 楼是源码么...
单用 is_numeric 过滤,可以被 16 进制绕过,某些情况下可以注入的...

[goodryb]

30 说的有道理，不过不想这么复杂的话，还是建议用 RDS 测试一下，先买个按量的实例，扛不住了就换个高规格的，没问题之后再买个包年包月的
当然了，省事就是费钱，量上来之后不行买高规格就搭配 redis 做缓存，没必要这么纠结

[qq915458022]

@quericy 谢谢提醒，已经换成 is_int