最近发表的话题
最近发表的评论
  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 6个月前

    @ziyanziyu 常规来说都是一个job或者event定义对订单的业务处理流程吧,那么对每个订单的处理都是一样的啊,也就是很多个定时任务都只对应一个job或者event处理器,对吧

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 6个月前

    @ziyanziyu 不是的,每个定时任务创建的时候需要给一个唯一Key来做ID,移除用这个ID来操作,用相同ID来再创建新的任务会对相同ID执行更新操作,这样可以对接队列的时候很方便的确保不会重复创建很多个相同任务

    Forsun::plan("{$prefix}:{$order_id}")

    上边这个操作就是制定这个定时任务的ID

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 6个月前

    @Stone007 为何?

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @仰望 其实也是很简单的啊,用户下单的时候订单完成写入数据库拿到订单id之后,根据订单id创建一个延时任务或者根据订单生成时间自动计算生成一个固定时间任务都行

    任务到期之后可以触发一个event或者执行一个job都行,触发event的之后任然会执行监听了该Event对应的job了

    Forsun::plan("{$prefix}:{$order_id}")->job(new OrderTimeoutHandler())->at('2018-03-14 10:21:22');
    
    // or
    
    Forsun::plan("{$prefix}:{$order_id}")->event("order.timeout", ['oder_id' => $order_id])->delay(20);

    固定时间任务区别延时任务的好处是因为针对相同name创建的任务重复创建会覆盖,所以但异常或是容错系统自动纠正的时候可以很方便的根据下单时间重新计算过期时间再次创建任务或者直接处理过期

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @颜⑧ kafla laravel本省没有支持,应该没人用吧,而且感觉laravel队列设计似乎用来支持kafla这样比较大的队伍做worker似乎有点吃力啊,大多数情况下每天亿级别这种消息量,beanstalk还是可以的

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @蜗牛 就是你刚才说的这个场景啊,常规做法都是在订单写入数据库后,后台轮询不断查询数据库然后处理的方式,但这样有很多缺点,第一无法自动支持多台机器并行处理,第二订单量比较大的情况下会造成数据库压力非常大,第三在一个相对比较复杂的系统中,一个订单可能有很多个不同定时任务的要求,这样处理量就会非常恐怖了,第四就是主备容灾、自动扩容、监控和一定程度的自动伸缩性的要求了

    我们现在每天基本都是数十万的订单量,而且经常会出现订单突然翻倍的情况,一个订单又有接近五六个不同长时定时任务要求,如果轮询扫描数据哭的话,基本每次要扫描数百万订单,如果不是独立的定时任务管理系统,通过直接入定时任务系统,配合修改过的队列系统,省去了大量重复读写数据库的压力才能高效处理。

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @leo 这个强不强大的团队也没什么关系吧,如果你有实际负责使用或者认真研究一下beanstalk这样的代码,就会发现其本省就有很多问题,这也是在实际的系统中运用出来的,并不是有这个功能就是在相对要求更高之下还能很好的运作,laravel的队列设计本省来说还是很弱的,并不适合处理大量任务的情况,我们也是踩了很多坑才得出来的,job + delay实在很弱也要实际在项目中使用才能发现,我分享的也是每秒几千job这样中型项目负责度的一个解决方案,更高需求的时候当然也要更好的方案才行,当然这也是仁者见仁智者见智了

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @leo 有啊,比如说用户下单的时候同时创建一个支付提醒任务,五分钟还未完成付款就给用户推送一条消息提醒,虽然也可以用轮询查询数据库的方式,但是如果订单量增高的话,这样很容易挂的

    这样的场景不要太多了吧,电商的订单超时、支付超时、发货超时、收货超时,快递业务的配送超时等等,虽然都可以用常规crontab轮询数据库的方式,但是随着业务的增长和负责话,轮询的查询量会指数级增长,而且轮询的方式本身是没有办法直接扩容到多台机器的

    说到redis队列,redis本身并不是为了队列实现的,只是用了list数据结构近似当作队列,延时也不是一个feature,其每秒能处理的量并没有你想的那么高
    另外一个本身就是队列的beanstalk的性能都很低,更不用说database的方式了

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @leo job + delay 参数确实可以产生延时任务,区别只是性能和扩展性可管理性

  • 高性能千万级定时任务管理服务 forsun Laravel 插件使用详解 at 8个月前

    @leo
    如果你仔细研究那么就应该知道,laravel自带的cron只能预先定义而不能在controller和job中动态添加,而且依赖系统crontab也不能很好的跨机器做分布式
    第二laravel自带的cron能添加的任务是有限的,顶多几百已经很多了,但在实际项目中有很多都需要很多定时任务的情况,比如像饿了么的超过十五分钟不付款取消顶多,商家超过五分钟取消订单退款等等,这样的都是动辄百万以上的定时任务
    第三就是延时任务的问题,虽然queue自带了delay参数,但是很多queue实现的delay并不是很理想,性能和可维护性都很低,一个高性能可管理的延时任务还是很需要的