1. Надежная доставка на стороне производства
1. 保障消息的成功发出
2. 保障MQ节点的成功接收
3. 发送端收到MQ节点（broker）确认应答
4. 完善的消息补偿机制
В реальном производстве трудно обеспечить полную надежность первых трех пунктов.Например, в экстремальных условиях производитель не может отправить сообщение, и отправитель внезапно испытывает сетевую вспышку при получении подтверждающего ответа. трудно обеспечить надежность доставки, поэтому есть четвертый пункт полного механизма компенсации сообщений.
2. Решения для крупных интернет-компаний
第一种：消息落库，对消息状态进行达标。具体来说就是将消息持久化到数据库并设置状态值，收到消费端的应答就改变当前记录的状态。再用轮询去重新发送没接收到应答的消息，注意这里要设置重试次数。
第二种：消息的延迟投递，做二次确认，回调检查。
3. Сообщение сохраняется в библиотеке, а статус сообщения помечается
Блок-схема библиотеки перетаскивания сообщений
После того, как бизнес-данные и сообщения сохранены, введите setp2 и отправьте сообщение в службу MQ.Согласно обычному процессу, потребитель прослушивает сообщение, изменяет статус сообщения как потребляемого в соответствии с уникальным идентификатором и дает Подтверждающий ответ ack для Listener. Если возникает непредвиденная ситуация, потребитель не получает или слушатель получает подтверждение, а сеть прерывается, и его нельзя получить, В это время нам нужно использовать нашу распределенную задачу синхронизации, чтобы получить те тайм-ауты, которые не были получено из базы данных msg.сообщения, отправьте его повторно. В механизме повторов должно быть установлено ограничение на количество повторов, из-за каких-то внешних причин отправка все время не проходит, нельзя повторять слишком много раз, иначе будет тянуться весь сервис. Например, если это не удается после трех попыток, установите статус сообщения на 2, а затем вручную обработайте его через механизм компенсации. В реальном производстве такая ситуация все же относительно редка, но без этого компенсационного механизма не обойтись, иначе надежности не добиться.
Чтобы увидеть реализацию кода, вы можете взглянуть на эту серию моих работ:woohoo.brief.com/from/from1785ahah6from…
4. Задержите доставку, сделайте вторичное подтверждение и вернитесь.
Вспоминая первое решение, производственная сторона должна хранить как бизнес-данные, так и данные сообщений.Действительно ли этот дизайн подходит для сценариев с высокой степенью параллелизма? В основной ссылке необходимо тщательно продумать каждое сохранение, и однократное сохранение занимает 100-200 миллисекунд, что невыносимо в сценариях с высоким параллелизмом. На данный момент нам нужно наше второе решение, блок-схема выглядит следующим образом.
Upstream Server — это наша восходящая служба, то есть производитель.После того, как производитель успешно сохраняет бизнес-данные, генерируются два сообщения, одно немедленно отправляется на нижестоящий сервер downstream, а другое — отложенное сообщение в компенсационную службу. сервер обратного вызова.
Обычно, когда подчиненная служба прослушивает это мгновенное сообщение, она отправляет сообщение на сервер обратного вызова.Обратите внимание, что вместо метода return ack в первом решении сообщение отправляется обратно.
Сервер обратного вызова прослушивает это сообщение и знает, что сообщение было успешно обработано только что, а затем сохраняет это сообщение в базе данных.Когда отложенное сообщение, отправленное вышестоящей службой, достигает сервера обратного вызова, сервер обратного вызова обращается к базе данных, чтобы запрашивать, была ли нижестоящая служба только что обработана. Соответствующее сообщение было обработано. Если в его базе данных сообщений есть эта запись, это означает, что сообщение было использовано. Если эта запись не существует, сервер обратного вызова инициирует запрос RPC к вышестоящей службе, сообщая вышестоящей службе. , вы просто не отправили сообщение успешно, вам нужно повторно отправить его, вышестоящая служба повторно отправит немедленное и задержанное два сообщения и продолжит предыдущий процесс.
Хотя второе решение не может обеспечить 100% надежную доставку, в особо экстремальных случаях необходимы временные задачи и механизмы компенсации. Но суть второго решения заключается в сокращении операций с базой данных, что очень важно!
В сценариях с высоким параллелизмом я думаю не о 100% надежности, а о доступности и о том, сможет ли производительность справиться с этим трафиком, поэтому, если я могу сократить одну операцию с базой данных, я уменьшу ее один раз. Моя восходящая служба сокращает одну операцию с базой данных, производительность моей службы относительно повышается, а служба компенсации асинхронного обратного вызова может быть отделена.
V. Заключение
Оба решения выполнимы и должны быть выбраны в соответствии с реальным бизнесом.Второе решение будет выбрано для крупномасштабных сценариев сверхвысокого параллелизма, а первое решение может использоваться для обычных сценариев.