有人在关注或者使用 Laravel 消息队列吗？交流一下吧
大家都用的什么方案呢？内置的吗？
有没有在用亚马逊的队列服务？
阿里云的也在公测中
有关队列的其它经验也可以传授一下，谢谢。
本帖已被设为精华帖！
附加内容, 使用此功能的话, 会给所有参加过讨论的人发送提醒.
我就说一点我的时间经历吧.
如果需要实现自己的queue servier，也很简单.
继承Illuminate\Queue\Queue，并且实现接口Illuminate\Queue\QueueInterface。
在app\start\global.php或者其他启动载入文件, 里面添加一个
Queue::extend('{driverName}', function($config) {
return new {driverClass}($config);
即可(记得修改queue.php中得connections和driver)。
建议直接使用beanstalkd，简单直接。如果本身就已经在使用redis作为缓存的话，那就更好，直接用redis了。
看楼主经历有限，直接就上beanstalk吧.
目前我们用的redis queue遇到了一个问题，就是进入队列的延时任务可能需要在时间未到得情况下将其删除，redis队列做不到. 看了一下beanstalk能够做到打算一步切换过去。
个人经验小tips
另外在队列的fire中不要使用任何有关任何某个队列driver的独有方法，以后切换队列的时候比较麻烦。
切换队列的时候，如果之前还有任务还没有结束可以多个driver一起跑。 详细可见:
artisan queue:work -h
另外有一个问题@Summer ,
我看代码queue:listen是主循环不停的调用queue:workcommand实现的，这样的用意是什么啊？ 可能会有点慢？
Queues 在 Laravel 里面是特别好用. 可以试试你说的商业方案, 要看他们具体的实现是什么, Laravel 是否支持等.
1. 使用 Beanstalkd
开发环境 , Homestead 里面集成了 B
这里是 Homestead 里 Beanstalkd 的 ;
2. 使用 Redis
开发环境 , Homestead 里面集成了 R
这里是 Homestead 里 Redis 的 ;
Redis 和 Beanstalkd 都是非常成熟的队列方案, Laravel 提供的
接口也是特别的方便, 可读性更是超棒 :sparkles: :sparkles: :sparkles:
我的需求主要是延时写入操作日志到数据库和用户自主群发短信，不知道怎么样处理合适。
可以试试Beanstalkd，这个可以自己配置。你说都都是商业项目了，有钱的话用他们最方便了。
另外 Redis 是默认支持的, Beanstalkd 需要安装 Package 进行支持, 还有 Laravel 支持 Amazon SQS
的, 跟 Beanstalkd 一样, 都需要另外安装 Package 来支持, 详细见:
下面的注释在 app/config/queue.php 文件里面可以找到.
|--------------------------------------------------------------------------
| Default Queue Driver
|--------------------------------------------------------------------------
| The Laravel queue API supports a variety of back-ends via an unified
| API, giving you convenient access to each back-end using the same
| syntax for each one. Here you may set the default queue driver.
| Supported: "sync", "beanstalkd", "sqs", "iron"
Laravel 5 也将支持 database queue driver
单兵作战，时间、技术与运维精力都有限，所以想采用一些成品的商业产品。
国内的消息队列服务，搜索了一下，阿里云的内测产品，还有 leancloud 的类似产品。
国外的比较多，Laravel 也内置了接口，不知道国内使用时在实际运营时稳定性咋样。今天打算试一下国外的产品。再研究一下 Beanstalkd，Redis 放在项目最后研究。数据库缓存方案还不确定。
研究一下看看
oldsound/rabbitmq-bundle
Ctrl+Enter
上可以了解更多 Laravel 的 package.
社区会员: 1001
主题数: 513
评论数: 2688能详细的说下吗，整天听到队列，头都疼了，百度也找不到好的解释
首先，队列是一种数据结构，用链表和数组都可以实现，队列的特点就是先放入队列的数据先出队列。不过看到话题标签有Redis，猜测题主想问的应该是现在很广泛使用的消息队列(MQ)。这里的消息不只是简单的文本信息，也可以是序列化后的对象。现在比较流行的开源消息队列系统有Beanstalkd,RabbitMQ,Redis(可以作为队列系统使用)等，其核心作用都是先将消息数据通过系统接口按顺序放入队列(暂存于内存)，需要时再按放入的顺序依次取出以作后续处理。就拿我前段时间做的邮件发送系统举例：系统以HTTP协议提供服务，对外提供的主要功能是发送邮件，API地址为 /api/msg.send。使用者只要以POST请求此地址，传入subject,body,recipient这三个参数，即可发送一封邮件。方案1： 不使用数据库，不使用队列请求接口时，控制器直接调用sendmail或外部smtp服务器发送邮件，整个发送过程HTTP请求处于等待状态，待邮件发送完成，返回发送结果（只是调用发送程序是否成功的结果，不是邮件真正的发送结果，真正发送结果需要分析邮件日志) 这个方案最简单直接，平时发送少量邮件是可以的，但是缺点也很明显： 1. 因为接口调用时整个邮件发送过程都是同步进行的，每次请求都要等待邮件发送端完成处理，必然导致每次调用接口的等待时间增长。2. 当系统接口并发请求较高时，系统可用性不仅受限于WebServer的处理能力，还完全受限于邮件发送端软件的处理能力，其中任一环节故障就会导致整个系统无法提供服务。3. 若邮件发送端软件出现故障（比如SMTP连接超时），导致某次请求时邮件发送失败，那这封邮件内容便彻底丢失了，系统没有任何存留，不能实现自动重发。方案2： 使用数据库，不使用队列请求接口时，将要发送的邮件信息存入数据库,表结构如下：id | subject | body | recipient | sent_at | failed_at | failed_times然后在服务器上运行一个定时任务，每秒一次读取 sent_at=0 && failed_times & 10 的记录，随后调用邮件发送端发送邮件，成功后把sent_at设为当前时间，失败后设置failed_at并累加failed_times。 方案2已经用到了类似队列的思想。相对于方案1的提升：1. 去掉了同步发送邮件的操作，接口请求响应会快很多2. 邮件发送失败后可以重发，邮件不会丢失3. 当邮件发送端完全失效后系统也可以接受邮件发送请求，待发送端恢复后可以继续发送邮件。但还是存在缺点： 每次请求都会写一次数据库，当大并发量或者大数据量（一次请求包含100万个收件人）时，数据库负载过高影响稳定性，同时也会严重增加接口的响应时间（一下子写入100万条记录不是闹着玩的）方案3： 数据库 + 队列请求接口时，将要发送的邮件信息以JSON格式存入队列系统，放入的单个消息形如：{
"subject" : "今天没吃药",
: "感觉自己",
"recipient"
: ""}现在的队列基本上都是内存队列，数据存取非常快，一瞬间写入100万条数据再也不是难事。随后，在服务器上运行一个常驻进程任务(Worker)，实时监听队列中是否有新的消息（Job,此处指邮件信息）。当新消息进入时，从队列中取出消息，调用邮件发送端完成处理，发送成功后将此消息销毁并将消息内容插入数据库（同方案2），如果发送失败，将此消息重新放入队列，并加入一个60秒的延时标记，意味60秒后再取出处理。这样改进后整个系统的吞吐量和响应速度将大大提升，而且同时也让系统支持了分布式运行的能力。每个Worker进程都可以视为一个处理节点，倘若把worker分散到不同的服务器上，便实现整个系统的分布式处理了，这也是队列的一个重要特性之一。在我实际项目中还是做了许多基于方案3的改进，对于群发还使用了邮件列表和邮件模板等设计，整个系统类似Mailgun和Sendcloud的设计，等整个系统稳定下来，我会考虑将代码开源到Github。这个例子只是队列的一个常见使用场景，一般来说在需要缓解数据库写入压力的场景下面，都可以考虑使用消息队列，还有一些需要分布式处理的情况下，也是队列很好的使用场景。现在大部分语言都有成熟的消息队列处理组件，可以很方便的使用各种队列系统，比如我常用的Laravel 便原生支持了 Beanstalkd,Amazon SQS,IronMQ,Redis。抱砖引玉，不足之处请指正，谢谢。
Fullstack猿.淘宝官方提供，安全、快捷！在Laravel中使用自己的类库三种方式 - 推酷
在Laravel中使用自己的类库三种方式
虽然Composer使得我们可以重用很多现有的类库（例如packagist.org中的），但是我们仍然可能用到一些不兼容composer的包或者类库。另外在某一项目中，我们也可能会创建某一类库，而且可能并没有制作成为composer package 的打算。这个时候我们可以通过以下方式来使用自己的特有类库。
增加可直接实例化的类
有些需要直接在项目中使用的类，可以通过以下方式增加到Laravel中
创建类库文件
app/libraries/class/myClass.php
写入文件内容
&?phpclassMessage{publicstaticfunction display(){}}?&
app/start/globals.php
中增加类导入路径
&?php ClassLoader::addDirectories(array(
app_path().'/commands',
app_path().'/controllers',
app_path().'/models',
app_path().'/database/seeds',
app_path().'/libaries/class',// 在这里增加));?&
composer.json
中增加autoload目录
&autoload&:{&classmap&:[&app/commands&,&app/controllers&,&app/models&,&app/database/migrations&,&app/database/seeds&,&app/tests/TestCase.php&,&app/libraries/class&//在这里增加]},
composer dump-autoload
来创建导入映射
使用自己导入的类直接调用
Message::display()
这种方法同样也是增加队列类的方法，很多人不知道Laravel中队列处理类应该放在哪里，其实按照上面的方法，在
目录下创建一个
目录，然后让其可以直接实例化即可
增加可直接调用的函数
有人喜欢用
var_dump()
，想要在Laravel中这么做也非常容易
创建一个函数文件
app/libraries/function/helper.php
写入文件内容
&?php function v($msg){
var_dump($msg);}?&
把文件增加到composer自动导入列表中
&autoload&:{&classmap&:[...],&files&:[&app/libraries/function/helper.php&],},
或者在项目中显示
这个文件。打开
app/start/global.php
，在末尾增加：
require app_path().'/libraries/function/helper.php';
个人感觉这两种方式都OK，如果想要控制这个文件加载的时间，甚至可以在
filter.php
文件中增加以下内容
App::before(function( $request ){require(&{$GLOBALS['app']['path.base']}/app/libraries/function/helper.php&);});
在项目中直接使用函数
v('hello world')
增加稍微复杂的类库
有的时候一个类库不仅仅是一个文件那么简单，因此下面的方式更加适合有多个文件多个结构的类库。
标准的目录结构。
MyappSearch(note directory is capitalized)Search.php
SearchFacade.php
SearchServiceProvider.php
AnotherLib
Myapp/Search/Search.php
类的命名空间为
Myapp\Search
修改composer中autoload
&autoload&:{&classmap&:[&app/commands&,&app/controllers&,&app/models&,&app/libraries&,&app/database/migrations&,&app/database/seeds&,&app/tests/TestCase.php&],&psr-0&:{&Myapp&:&app/libraries&}},
在项目中使用
new Myapp\Search\Search()
来实例化某一类
虽然Laravel没有强制哪种方式最好，但是有一定的标准可以使得项目结构清晰，多人合作开发时省去很多交流成本。
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见虽然Composer使得我们可以重用很多现有的类库（例如packagist.org中的），但是我们仍然可能用到一些不兼容composer的包或者类库。另外在某一项目中，我们也可能会创建某一类库，而且可能并没有制作成为composer package 的打算。这个时候我们可以通过以下方式来使用自己的特有类库。增加可直接实例化的类有些需要直接在项目中使用的类，可以通过以下方式增加到Laravel中创建类库文件app/libraries/class/myClass.php写入文件内容&?phpclassMessage{publicstaticfunction display(){}}?&在app/start/globals.php中增加类导入路径&?php ClassLoader::addDirectories(array(app_path().'/commands',app_path().'/controllers',app_path().'/models',app_path().'/database/seeds',app_path().'/libaries/class',// 在这里增加));?&在composer.json中增加autoload目录&autoload&:{&classmap&:[&app/commands&,&app/controllers&,&app/models&,&app/database/migrations&,&app/database/seeds&,&app/tests/TestCase.php&,&app/libraries/class&//在这里增加]},执行composer dump-autoload来创建导入映射使用自己导入的类直接调用Message::display()即可这种方法同样也是增加队列类的方法，很多人不知道Laravel中队列处理类应该放在哪里，其实按照上面的方法，在app目录下创建一个queues目录，然后让其可以直接实例化即可增加可直接调用的函数有人喜欢用v()来代替var_dump()，想要在Laravel中这么做也非常容易创建一个函数文件app/libraries/function/helper.php写入文件内容&?php function v($msg){var_dump($msg);}?&把文件增加到composer自动导入列表中&autoload&:{&classmap&:[...],&files&:[&app/libraries/function/helper.php&],},或者在项目中显示require这个文件。打开app/start/global.php，在末尾增加：require app_path().'/libraries/function/helper.php';个人感觉这两种方式都OK，如果想要控制这个文件加载的时间，甚至可以在filter.php文件中增加以下内容App::before(function( $request ){require(&{$GLOBALS['app']['path.base']}/app/libraries/function/helper.php&);});在项目中直接使用函数v('hello world');增加稍微复杂的类库有的时候一个类库不仅仅是一个文件那么简单，因此下面的方式更加适合有多个文件多个结构的类库。创建psr0或者psr4标准的目录结构。librariesMyappSearch(note directory is capitalized)Search.phpSearchFacade.phpSearchServiceProvider.phpAnotherLibMyapp/Search/Search.php中Search类的命名空间为Myapp/Search。修改composer中autoload&autoload&:{&classmap&:[&app/commands&,&app/controllers&,&app/models&,&app/libraries&,&app/database/migrations&,&app/database/seeds&,&app/tests/TestCase.php&],&psr-0&:{&Myapp&:&app/libraries&}},在项目中使用new Myapp/Search/Search()来实例化某一类总结虽然Laravel没有强制哪种方式最好，但是有一定的标准可以使得项目结构清晰，多人合作开发时省去很多交流成本。参考
无相关信息