欢迎关注我的公众号：程序员技术成长之路
QPS，全称是Query Per Second，即每秒查询次数。它是一种衡量系统处理能力的重要指标。"每秒1万"的QPS对于一般的个人网站或者中小型网站来说，是相当高的。但是对于大型网站、互联网公司或高并发系统来说，可能就略显不足。在大流量的互联网公司(比如BAT)的场景，其核心业务系统一般要求能够处理每秒数十万甚至上百万的QPS。所以说一个系统的QPS是否高，需要根据具体的业务场景和需求来判断。今天笔者就和大家来谈谈这个定义。
首先就互联网公司来说，如果按照1W/S来计算，我们计算一天有估计能够有10个小时（这是往高了去估，正常来说有8个小时的话这个公司都要烧高香了）106060*1w/s=24000w个请求，我们按照一个请求存储一条mysql数据，也就是24000w条数据，假设我们的表结构如下
CREATE TABLE `task_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `task_id` int(11) NOT NULL DEFAULT '0', `name` varchar(32) NOT NULL, `spec` varchar(64) NOT NULL, `protocol` tinyint(4) NOT NULL, `command` varchar(256) NOT NULL, `timeout` mediumint(9) NOT NULL DEFAULT '0', `retry_times` tinyint(4) NOT NULL DEFAULT '0', `hostname` varchar(128) NOT NULL DEFAULT '', `start_time` datetime DEFAULT NULL, `end_time` datetime DEFAULT NULL, `status` tinyint(4) NOT NULL DEFAULT '1', `result` mediumtext NOT NULL, PRIMARY KEY (`id`), KEY `IDX_task_log_protocol` (`protocol`), KEY `IDX_task_log_status` (`status`), KEY `IDX_task_log_task_id` (`task_id`)
- bigint: 8字节
- int: 4字节
- tinyint: 1字节
- varchar: 1字节/字符（这里仅考虑英文字符，非英文字符存储占用根据字符集会有不同）
- mediumtext: 最大16MB，但实际占用大小取决于实际存储的数据长度
- datetime: 8字节
根据你的表结构，每一行数据的大小大概如下：
id: 8字节task_id: 4字节name: 32字节spec: 64字节protocol: 1字节command: 256字节timeout: 3字节（mediumint占3字节）retry_times: 1字节hostname: 128字节start_time: 8字节end_time: 8字节status: 1字节result: 取决于实际存储的数据长度，最长约16MB
所以，除了result字段之外，其余字段固定长度总计大约514字节，result字段的长度会根据实际存储的数据大小而变。因此，如果我们不考虑result字段，那么每行数据大约占用514字节。如果考虑result字段，那么每行数据的大小就需要根据实际插入的数据来进行计算了。那我们就按照514字节来计算，那么我们可以得出一共需要使用的存储大小为:
24000w行 * 514字节/行 = 1233600000000 字节 = 1233600 MB = 1205.078125 GB = 1.1775TB
所以，总共约1.18TB。
以上可以得出1W/S的QPS对于一般企业可以来说是非常巨大的量，一天的存储大小可以到达1TB，我们这就可以想象对于像腾讯、字节这种超大型互联网企业来他关存储成本就是一个很大的开支。这也是为什么他们那么注重基础，对于这种企业在设计数据库之初表结构设计就能够大大的关联的成本。
当然对于这种类似的企业，他们还有更多种的优化，像普通的Mysql其实是不能满足的，所以有的时候需要借助于其他大数据存储引擎来进行海量数据的存储。今天我只从存储成本来进行解释QPS 1W/S，可能我讲得比较简单。但是支持1W/S以上的还需要其他的配合，如缓存、负载均衡等多项技术来进行优化。如果级别到了百万QPS，那这个应用肯定是国民级别的，如容灾、异地多活也要考虑进去。
所以很多普通开发能够满足1W的请求已经是很了不起了。
路路漫漫其修远兮，吾将上下而求索。
