队列：
结构：是一种数据结构
方式：用链表和数组可以实现
特点：先放入队列的数据先出队列（先进先出）
方案1：不使用数据库，不使用队列
请求接口是时，控制器直接调用sendemail或者外部的smtp服务器发送邮件，整个发送过程HTTP请求处于等待状态，待邮件发送完成，返回发送结果，（只是调用发送程序是否成功的结果，不是真正的发送结果，真正的发送结果需要分析邮件日志）
这个方案最简单直接，平时发送少量邮件是可以的，但是缺点也是很明显：
1.因为接口调用时整个邮件发送过程都是同步进行的，每次请求都要等待邮件发送段完成处理，必然导致每次调用接口的等待时间增长。
2.当系统接口并发请求高时，系统可用性不仅受限WEBserver的处理能力，还完全受限于邮件发送端软件的处理能力，其中任一环节故障就会导致整个系统无法提供服务。
3.若邮件发送端软件出现故障（比如SMTP链接超时），导致某次请求时邮件发送失败，那这封邮件内容便彻底丢失了，系统没有任何存留，不能实现自动重发。
方案2：使用数据库，不使用队列
1.请求接口是，将要发送的邮件信息存入到数据库中，表的结构如下：
id|subject|body|recipient|sent_at|failed_at|failed_times
然后在服务器上运行一个定时任务，每秒一次的读取sent_at=0&failed_times<10的记录，随后用邮件发送段发送邮件，成功后把send_at设置为当前时间，失败后设置failed_at为当前时间并累加failed_times
相对于方案1的提示：
1.去掉了同步发送邮件的操作（可能性）.接口请求响应会快很多
2.邮件发送失败后可以重新重发，邮件不会丢失
3.当邮件发送端完全失效后系统也可以接受邮件发送请求，待发送端恢复后可以继续发送邮件
但还是存在缺点：
1.每次请求都会写一次数据库，当大并发量或者大数据量（一次请求包含100万个收件人）时，数据库负载过高影响稳定性，同时也会严重增加接口的响应时间；
方案3：数据库 + 队列
请求接口时，将要发送的邮件信息以JSON格式格式存入队列系统，放入的单个消息形如：
{
“subject”:"今天的天气情况"，
“body”:"今天天气晴朗",
"receipt":"106910307@qq.com"
}
现在的队列基本都是内存队列，数据存取非常快，一瞬间写入100万条数据不在是难事，随后在服务器上运行一个常驻进程任务（worker），实时监听队列中是否有新的消息。当有新的消息进入时，从队列中去出消息，调用邮件发送端完成处理，如果发送失败，将此消息重新放入队列，并加入一个60秒的延时标记，意味着60秒后取出处理。
这样改进后整个系统的吞吐量和响应速度将大大提升，而且同时也让系统支持了分布式运行的能力。每个Worker进程都可以视为一个处理节点，倘若把worker分散到不同的服务器上，便实现整个系统的分布式处理了，这也是队列的一个重要特性之一。
