Keen to make wheels, Qunar.com open source message middleware QMQ, Jingdong also engages in JMQ!

China Internet is keen on "making wheels"!

In the geek time message queuing master class, the columnist revealed that JD has its own message queuing product JMQ, and it will be released as an open source soon!

After that, I rarely paid attention to the news of JMQ. Today, by chance, I saw that Qunar also launched a message middleware QMQ.

According to the development team of Qunar, QMQ has been used internally for 6 years. The reason why I chose self-developed QMQ is because there was no "excellent and suitable for Qunar" MQ at that time.

First of all, because the technology stack Qunar excluded RabbitMQ developed by erlang, and the MetaQ of Kafka and the Java version of Kafka was not mature and stable at that time. And ActiveMQ has been used in many applications on Qunar, but the use process is not smooth: downtime, message loss, message blockage and other problems are not uncommon, and ActiveMQ has been developed for many years, the code is also very complex, and you want to control it completely. It's not easy, so Qunar decided to build a wheel on its own.

QMQ is currently being used extensively on Qunar. Including order scenarios closely related to transactions; also including high throughput scenarios such as quotation search. At present, the daily message qps within the company is around 60W, and nearly 4W+ message topics are carried in production, and the end-to-end delay of messages can be controlled within 10ms.

QMQ mainly provides the following features:

  • Asynchronous real-time messaging

  • Delayed/timed messages

  • Tag-based server filtering

  • Consumer side idempotent processing support

  • Consumer 端 filter

  • Dead letter message

  • Simple API used with Spring annotation

  • Provide rich monitoring indicators

  • Access OpenTracing

  • Distributed transaction

  • Message delivery trajectory

  • Automatic backup of historical messages

It seems that these are some good features, but they are still called re-engineering wheels.

Every team or programmer who builds the wheel has its own reasons for "have to build". such as:

  • I think my needs are unique, and the existing libraries just can’t meet them at some point

  • There is no specification for the old wheel, or the interface is too complicated, I don’t know how to use it, and it’s too difficult to understand

  • Need to add new functions to the old wheel, but the code of the old wheel is difficult to read and no one can ask, I don’t know when I can figure it out, I can’t see the result, and it’s easy to give up

  • I have limited horizons, I don’t know there are such wheels

  • Third-party libraries cannot be used for copyright reasons. For example, Google Android implements JVM (Google has filed a lawsuit with Oracle for a line of code), such as Ali YunOS implements JVM itself

  • I just want to exercise myself, because making wheels is very good for my design and coding ability, and it is also very good for understanding the business.

  • Make your own wheels, have a "sense of control", you can see and touch, step by step, you can iterate from small goals to big goals, and the small incentives for continuous success will give you the motivation to move forward.

  • There are many innovative elements (for myself) and a sense of accomplishment

  • I don’t believe in the old wheels. For example, the old wheels may have backdoors, loopholes (think about OpenSSL's heart bleeding loopholes), and if you want to modify them later, you are not sure. Anyway, I feel that I am more secure in making wheels.

  • Don’t want the key technology of your product to be in the hands of others, and don’t want your core user data to flow through other people’s systems

  • The wheels of others are not open, I just want to make a (cottage) one out so as to gain the right to speak or commercial benefits

Although it is ridiculed as making wheels, making wheels has the advantage of making wheels, that is, more programmers will be recruited. At the same time, if wheels are made, the pits dug are not easy to be replaced, and the risk of being laid off may be smaller if you enhance your competitiveness!

It is also a special learning significance for programmers to make wheels. Learning how others make them, understand the internal mechanism, and make them by yourself. This is also a very good opportunity for exercise.

Finally, let me say that after QMQ is open source, we may have one more choice when using message queues. However, the QMQ community is relatively backward after all, and if you encounter a problem, you may not be able to solve it yourself. Therefore, use it with caution in the early stage!

Guess you like

Origin blog.51cto.com/15127565/2665022