18
回答
用100多行代码实现了一个异步队列 -- 两个凡是
【腾讯云】学生服务器套餐10元/月 >>>   

可以和rabbitmq 啥的PK一下

物化事务性队列,更可靠

<无标签>
举报
宏哥
发帖于1年前 18回/1K+阅
共有18个评论 最后回答: 1年前
所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。
--- 共有 2 条评论 ---
小宏的爹敢质疑我儿子 @宏哥 ,分分钟干死你 1年前 回复
朱__朱和它认真你就输了.... 1年前 回复

引用来自“AutoPlus”的评论

所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。

小屁孩, 有没有见过下面几个字:


可靠性

不知道内存可以映射块设备?

你们这些小屁孩,就是天天加班检查数据丢失做屌丝的命

引用来自“宏哥”的评论

引用来自“AutoPlus”的评论

所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。

小屁孩, 有没有见过下面几个字:


可靠性

不知道内存可以映射块设备?

你们这些小屁孩,就是天天加班检查数据丢失做屌丝的命

先把消息队列的定义搞清楚,你连最基本的概念都不懂,在这里胡吹一起。谁告诉你消息队列是要“可靠”的? 消息队列的目的是分流、后台透明的异步调度。消息队列都是几十个上百个一起并行,并且有另外几十个作为备用,随便掉几个几十个都有接替者。秒杀、投票这种系统,只会关注投放的流量,谁会关注是不是所有的投票都被系统记录?只要记录 90% 就足够好。

要的是量大,反应迅速,热切换,而不是“可靠”,Understand?

你知道内存映射是什么概念吗?你写过 C mmap 吗,也在这里谈内存映射。内存映射只能映射文件的 a 到 b 个字节,是用来做缓冲区用的。你的数据都存储在 a 到 b 之间?不 seek?那你的 PG 数据库还有什么存在的意义。

引用来自“AutoPlus”的评论

引用来自“宏哥”的评论

引用来自“AutoPlus”的评论

所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。

小屁孩, 有没有见过下面几个字:


可靠性

不知道内存可以映射块设备?

你们这些小屁孩,就是天天加班检查数据丢失做屌丝的命

先把消息队列的定义搞清楚,你连最基本的概念都不懂,在这里胡吹一起。谁告诉你消息队列是要“可靠”的? 消息队列的目的是分流、后台透明的异步调度。消息队列都是几十个上百个一起并行,并且有另外几十个作为备用,随便掉几个几十个都有接替者。秒杀、投票这种系统,只会关注投放的流量,谁会关注是不是所有的投票都被系统记录?只要记录 90% 就足够好。

要的是量大,反应迅速,热切换,而不是“可靠”,Understand?

你知道内存映射是什么概念吗?你写过 C mmap 吗,也在这里谈内存映射。内存映射只能映射文件的 a 到 b 个字节,是用来做缓冲区用的。你的数据都存储在 a 到 b 之间?不 seek?那你的 PG 数据库还有什么存在的意义。

回去捡数据吧,

可怜的小孩

不需要可靠就简单了

<?PHP
define('APPPATH',__DIR__);
define('RUNPATH',__DIR__);
require_once ('/var/www/pexcel/system/app_load.php');
Pexcel::modules( array(
    'runconfig'=>RUNPATH,
    'database'=>'/var/www/pexcel/modules/database/',
    )
);

$ip = msg_get_queue(12340);
$token = Profiler::start('aidi','send');

for($i = 0;$i<10000;$i++){
    msg_send($ip,2,"Test Message: ".$i ,false,false,$err);
    //var_dump(msg_stat_queue($ip));
}
Profiler::stop($token);
var_dump(Profiler::total($token));



引用来自“AutoPlus”的评论

引用来自“宏哥”的评论

引用来自“AutoPlus”的评论

所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。

小屁孩, 有没有见过下面几个字:


可靠性

不知道内存可以映射块设备?

你们这些小屁孩,就是天天加班检查数据丢失做屌丝的命

先把消息队列的定义搞清楚,你连最基本的概念都不懂,在这里胡吹一起。谁告诉你消息队列是要“可靠”的? 消息队列的目的是分流、后台透明的异步调度。消息队列都是几十个上百个一起并行,并且有另外几十个作为备用,随便掉几个几十个都有接替者。秒杀、投票这种系统,只会关注投放的流量,谁会关注是不是所有的投票都被系统记录?只要记录 90% 就足够好。

要的是量大,反应迅速,热切换,而不是“可靠”,Understand?

你知道内存映射是什么概念吗?你写过 C mmap 吗,也在这里谈内存映射。内存映射只能映射文件的 a 到 b 个字节,是用来做缓冲区用的。你的数据都存储在 a 到 b 之间?不 seek?那你的 PG 数据库还有什么存在的意义。

你们这些小屁孩做出来乱七八糟的系统

“只要记录 90% 就足够好。

对上面这句话, 你们的老板应该离开让你滚蛋了。

完全就是废物一个!!!!

什么叫做90% 80%....

数据错了要消息做什么

--- 共有 1 条评论 ---
mark35数据不值钱咋干都行 1年前 回复

引用来自“宏哥”的评论

引用来自“AutoPlus”的评论

引用来自“宏哥”的评论

引用来自“AutoPlus”的评论

所有的队列都从数据库的文件系统,也就是磁盘读取?而且基于你这个是关系数据库,分布是够呛的了。假设磁盘读取时间 0.1s,内存读取只需要 0.001s,是 100 倍性能差距(考虑到索引,磁头转动和寻道,以及不能分布,这个倍数应该更高)。

对比一下,rabbitmq、kafka、redis,ta 们基本是相似的 --- 内存存储,大量使用哈希进行键值检索,可以分布(比如 Twitter 的 twemproxy 可以把单台 Redis 水平扩展为上百台甚至更多)。架设是 100 台服务器就可以了,那么 1000万的请求,除去负载计算,可以被分流为 10到20万左右的请求。

对于1000万请求量,你这关系数据库写的队列需要 1000万 * 0.1s 的时间完成任务。内存数据库(特别是专业的消息队列)需要 1000万/100 * 0.001s。

小屁孩, 有没有见过下面几个字:


可靠性

不知道内存可以映射块设备?

你们这些小屁孩,就是天天加班检查数据丢失做屌丝的命

先把消息队列的定义搞清楚,你连最基本的概念都不懂,在这里胡吹一起。谁告诉你消息队列是要“可靠”的? 消息队列的目的是分流、后台透明的异步调度。消息队列都是几十个上百个一起并行,并且有另外几十个作为备用,随便掉几个几十个都有接替者。秒杀、投票这种系统,只会关注投放的流量,谁会关注是不是所有的投票都被系统记录?只要记录 90% 就足够好。

要的是量大,反应迅速,热切换,而不是“可靠”,Understand?

你知道内存映射是什么概念吗?你写过 C mmap 吗,也在这里谈内存映射。内存映射只能映射文件的 a 到 b 个字节,是用来做缓冲区用的。你的数据都存储在 a 到 b 之间?不 seek?那你的 PG 数据库还有什么存在的意义。

你们这些小屁孩做出来乱七八糟的系统

“只要记录 90% 就足够好。

对上面这句话, 你们的老板应该离开让你滚蛋了。

完全就是废物一个!!!!

什么叫做90% 80%....

数据错了要消息做什么

数据错了要消息做什么

---------------------------------------------------------------------

明显说明你就没玩过消息队列,孤陋寡闻。“消息队列的目的是采集”,理解?

你知道采集是什么意思?谁告诉你采集要 100%的可靠?采集的目的不是为了获取每个人提交的数据,而是为了获取大量的数据。

1000 个人提交了数据,你100%采集了1000个数据,这没有任何意义!你的数据量太小,是小学生才玩的东西。10000000个人提交了数据,你80%采集了8000000个数据,这就是采集的意义,这就是消息队列的意义!这就是为智能识别准备资源的意义!


普及架构图


LB ------ server node 1 ----- Memory Queue  --+ 
          server node 2 ----- Memory Queue  --+--+  
          server node 3 ----- Memory Queue  --+  |async 
                                                 |
                        +------------------------+ 
                        | async
                        +
                  background worker
                  |         |       |
                  |         |       |
               Database    FS      ...




顶部