Best Practice For Broker

Apache RocketMQ
Documentation
Blog
Community
Users
About

User Guide
    Why RocketMQ
    Quick Start
    Simple Example
    Order Example
    Broadcasting Example
    Schedule Example
    Batch Example
    Filter Example
    Logappender Example
    OpenMessaging Example
    Transaction Example
    FAQ
Release Notes
    Download
Deployment & Operations
    Architecture
    Deployment
    CLI Admin Tool
Contributor Guide
    How To Contribute
    Code Guidelines
    Manage Pull Request
    Release Manual
Best Practice
    Core Concept
    Broker
    Producer
    Consumer
    NameServer
    JVM/Kernel Config

Best Practice For Broker

Some useful tips for users.
On This Page

Broker Role
FlushDiskType
ReentrantLock vs CAS
os.sh

Broker Role

Broker Role is ASYNC_MASTER, SYNC_MASTER or SLAVE. If you cannot tolerate message missing, we suggest you deploy SYNC_MASTER and attach a SLAVE to it. If you feel ok about missing, but you want the Broker to be always available, you may deploy ASYNC_MASTER with SLAVE. If you just want to make it easy, you may only need a ASYNC_MASTER without SLAVE.
FlushDiskType

ASYNC_FLUSH is recommended, for SYNC_FLUSH is expensive and will cause too much performance loss. If you want reliability, we recommend you use SYNC_MASTER with SLAVE.
ReentrantLock vs CAS

to be finished
os.sh

to be finished

Updated: December 25, 2016
Share on
Twitter Facebook Google+ LinkedIn
Previous
Next
Leave a Comment
Apache Software Foundation

Follow: Twitter GitHub Feed 

Copyright © 2020 The Apache Software Foundation. Licensed under the Apache License, Version 2.0.
Apache RocketMQ, RocketMQ, Apache, the Apache feather logo and the Apache RocketMQ logo are trademarks of The Apache Software Foundation.

License | Security | Thanks | Sponsorship