成都网站建设外贸,百度智能门户建站怎么样,关键词优化营销,网站建设与规划专业主要原因#xff1a;是在高并发情况下#xff0c;由于来不及同步处理#xff0c;请求往往会发生堵塞#xff0c;比如诸多的insert、update之类的请求同时到达mysql#xff0c;直接导致无数的行锁表锁#xff0c;甚至最后请求会堆积很多#xff0c;从而触发大量的too man…主要原因是在高并发情况下由于来不及同步处理请求往往会发生堵塞比如诸多的insert、update之类的请求同时到达mysql直接导致无数的行锁表锁甚至最后请求会堆积很多从而触发大量的too mang connnections错误。通过消息队列我们可以异步处理请求从而缓解系统的压力。 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- MQmessage queue是一种跨进程的通信机制用于上下游传递消息。 mq的特点 1、先进先出 不能先进先出都不能说是队列了消息队列的顺序在入队时基本已经确定一般是不需要人工干预的。而且最重要的是数据是只有一条数据在使用中这也是mq在众多场景中被使用的原因。 2、发布订阅 发布订阅是一种很高效的处理方式如果不发生阻塞基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率这样的应用场景非常广泛。 3、持久化 持久化确保MQ的使用不只是一个部分场景的辅助工具而是让MQ能像数据库一样存储核心的数据。 4、分布式 在现在大流量、大数据的使用场景下只支持单体应用的服务器软件基本是无法使用的支持分布式的部署才能被广泛使用。而且MQ的定位就是一个高性能的中间件。 应用场景 基于上文所述的特点那么MQ就衍生出了很多的使用场景在大型的系统中应用非常广泛这里我们就列举一下常见的应用场景。 应用解耦异步 系统之间进行数据交互时在时效性和稳定性之间我们都要进行选择基于线程的异步处理能确保用户体验但在极端情况下可能会出现异常影响系统的稳定性而同步调用很多时候无法保证理想的性能那么我们就可以用mq来进行处理上游系统将数据投递到mq下游系统取mq的数据进行消费投递和消费可以用同步的方式处理因为mq接收数据的性能是非常高的不会影响上游系统的性能那么下游系统的及时率能保证吗当然可以不然就不会有下面的一个应用场景。 通知 这里就用到了前文一个重要的特点发布订阅下游系统一直在监听MQ的数据如果MQ有数据下游系统则会按照 先进先出 这样的规则 逐条进行消费 而上游系统只需要将数据存入MQ里这样既降低了不同系统之间的耦合度同时也确保了消息通知的及时性而且也不影响上游系统的性能。 限流 上文有说了一个非常重要的特性MQ 数据是只有一条数据在使用中。 在很多存在并发而又对数据一致性要求高而且对性能要求也高的场景如何保证那么MQ就能起这个作用了。不管多少流量进来MQ都会让你遵守规则排除处理不会因为其他原因导致并发的问题而出现很多意想不到脏数据。 数据分发 MQ的发布订阅肯定不是只是简单的一对一一个上游和一个下游的关系MQ中间件基本都是支持一对多或者广播的模式而且都可以根据规则选择分发的对象。这样上游的一份数据众多下游系统中可以根据规则选择是否接收这些数据这样扩展性就很强了。PS:上文中的上游和下游在MQ更多的是叫做生产者producer和消费者consumer 分布式事务 分布式事务是我们开发中一直尽量避免的一个技术点但是现在越来越多的系统是基于微服务架构开发那么分布式事务成为必须要面对的难题解决分布式事务有一个比较容易理解的方案就是二次提交。基于MQ的特点MQ作为二次提交的中间节点负责存储请求数据在失败的情况可以进行多次尝试或者基于MQ中的队列数据进行回滚操作是一个既能保证性能又能保证业务一致性的方案当然这个方案的主要问题就是定制化较多有一定的开发工作量。 应用示例 为了更加直观的展示MQ的应用场景这里我们就用一个常见的电商系统中的几个业务来具体说明下MQ在实际开发中应用场景。我们的实际场景大概是一个基于微服务架构的电商系统分为用户微服务、商品微服务、订单微服务、促销微服务等。基于微服务模式开发的系统MQ的使用场景更多下面我们逐一说明1、注册后我们可能需要做很多初始化的操作如调用邮件服务器发送邮件、调用促销服务赠送优惠劵、下发用户数据到客户关系系统等。那么这时候我们将这些操作去监听MQ当用户注册成功过后通过MQ通知其他业务进行操作。确保注册用户的性能。2、后台发布商品的时候商品数据需要从数据库中转换成搜索引擎数据基于elasticsearch那么我们应该将商品写入数据库后再写入到MQ然后通过监听MQ来生成elasticsearch对应的数据。3、用户下单后24小时未支付需要取消订单。以前我们可能是定时任务循环查询然后取消订单。实际上我更推荐类似延迟MQ的方式避免了很多无效的数据库查询将一个MQ设置为24小时后才让消费者消费掉这样很大程度上能减轻服务器压力。4、支付完成后需要及时的通知子系统进销存系统发货用户服务积分发送短信进行下一步操作但是支付回调我们都是需要保证高性能的所以我应该直接修改数据库状态存入MQ让MQ通知子系统做其他非实时的业务操作。这样能保证核心业务的高效及时。 注意事项 其实还有非常多的业务场景是可以考虑用MQ方式的但是很多时候也会存在滥用的情况我们需要清楚认识我们的业务场景发验证码短信、邮件这种过分依赖外部而且时效性可以接收几十秒延迟的其实更好的方式是多线程异步处理而不是过多依赖MQ。秒杀抢购确保库存不为负数更多的依赖高性能缓存如redis以及强制加锁千万不要依赖消费者最终的返回结果。实际工作中已经看到好几个这样的案例了上游-下游 这种直接的处理方式效率肯定是比 上游-MQ-下游 方式要高MQ效率高是因为我只是上游-MQ 这个阶段就当做已经成功了 转载于:https://www.cnblogs.com/pdd-666888/p/9447164.html
