Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon MQ untuk praktik terbaik ActiveMQ
Gunakan ini sebagai referensi untuk menemukan rekomendasi dengan cepat guna memaksimalkan performa dan meminimalkan biaya throughput saat bekerja dengan broker ActiveMQ di Amazon MQ.
## Jangan Pernah Memodifikasi atau Menghapus Antarmuka Jaringan Elastis Amazon MQ
Ketika Anda pertama kali [membuat broker Amazon MQ](getting-started-activemq.md), Amazon MQ menyediakan [antarmuka jaringan elastis](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) pada [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Introduction.html) di bawah akun Anda dan memerlukan sejumlah [izin EC2](security-api-authentication-authorization.md). Antarmuka jaringan memungkinkan klien Anda (produsen atau konsumen) berkomunikasi dengan broker Amazon MQ. Antarmuka jaringan dianggap berada dalam *lingkup layanan* Amazon MQ, meski merupakan bagian dari VPC akun Anda.
**Awas**
Anda tidak harus memodifikasi atau menghapus antarmuka jaringan ini. Memodifikasi atau menghapus antarmuka jaringan dapat menyebabkan koneksi hilang permanen antara VPC dan broker Anda.
![\[Diagram showing Client, Elastic Network Interface, and Amazon MQ Broker within a Customer VPC and service scope.\]](http://docs.aws.amazon.com/id_id/amazon-mq/latest/developer-guide/images/amazon-mq-network-configuration-architecture-vpc-elastic-network-interface.png)
## Selalu Gunakan Pooling Koneksi
Dalam skenario dengan produsen tunggal dan konsumen tunggal (seperti tutorial [Memulai: Membuat dan menghubungkan ke broker ActiveMQ](getting-started-activemq.md)), Anda dapat menggunakan satu kelas [http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html) untuk setiap produsen dan konsumen. Sebagai contoh:
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Establish a connection for the consumer.
final Connection consumerConnection = connectionFactory.createConnection();
consumerConnection.start();
```
Namun, dalam skenario yang lebih realistis dengan beberapa produsen dan konsumen, membuat sejumlah besar koneksi untuk beberapa produsen dapat menghabiskan banyak biaya. Dalam skenario ini, Anda harus mengelompokkan beberapa permintaan produsen menggunakan kelas [http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html). Sebagai contoh:
**catatan**
Konsumen pesan *jangan pernah* gunakan kelas `PooledConnectionFactory`.
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Create a pooled connection factory.
final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory();
pooledConnectionFactory.setConnectionFactory(connectionFactory);
pooledConnectionFactory.setMaxConnections(10);
// Establish a connection for the producer.
final Connection producerConnection = pooledConnectionFactory.createConnection();
producerConnection.start();
```
## Selalu Gunakan Transportasi Failover untuk Terhubung ke Beberapa Titik Akhir Broker
Jika aplikasi Anda perlu terhubung ke beberapa titik akhir broker—misalnya, ketika Anda menggunakan mode deployment [aktif/siaga](amazon-mq-broker-architecture.md#active-standby-broker-deployment) atau saat Anda [bermigrasi dari broker pesan on-premise ke Amazon MQ](https://docs.aws.amazon.com//amazon-mq/latest/migration-guide/)—gunakan [Transportasi Failover](http://activemq.apache.org/failover-transport-reference.html) untuk mengizinkan konsumen Anda terhubung secara acak ke salah satu titik akhir. Contoh:
```
failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-west-2.amazonaws.com:61617)?randomize=true
```
**penting**
Broker zona multi-ketersediaan dapat mengalami kegagalan selama jendela pemeliharaan dan restart broker. Gunakan Failover Transport untuk memastikan ketersediaan broker Anda.
## Hindari Penggunaan Penyeleksi Pesan
Anda dapat menggunakan [penyeleksi JMS](https://docs.oracle.com/cd/E19798-01/821-1841/bncer/index.html) untuk melampirkan filter ke langganan topik (untuk merutekan pesan ke konsumen berdasarkan kontennya). Namun, penggunaan penyeleksi JMS memenuhi buffer filter broker Amazon MQ, mencegahnya memfilter pesan.
Secara umum, buat agar konsumen tidak dapat merutekan pesan karena, untuk pemisahan yang optimal antara konsumen dan produsen, baik konsumen dan produsen harus bersifat sementara.
## Memilih Tujuan Virtual untuk Langganan Tahan Lama
[Langganan tahan lama](http://activemq.apache.org/how-do-durable-queues-and-topics-work.html) dapat membantu memastikan bahwa konsumen menerima semua pesan yang dipublikasikan ke topik, misalnya, setelah koneksi yang hilang dipulihkan. Namun, penggunaan langganan tahan lama juga menghalangi penggunaan konsumen yang bersaing dan mungkin memiliki masalah performa dalam skala besar. Pertimbangkan untuk menggunakan [tujuan virtual](http://activemq.apache.org/virtual-destinations.html).
## Jika menggunakan peering VPC Amazon, hindari klien IPs dalam rentang CIDR `10.0.0.0/16`
Jika Anda menyiapkan peering VPC Amazon antara infrastruktur on-premise dan broker Amazon MQ Anda, Anda tidak boleh mengonfigurasi koneksi klien dengan rentang CIDR. IPs `10.0.0.0/16`
## Menonaktifkan Penyimpanan dan Pengiriman Bersamaan untuk Antrean dengan Konsumen Lambat
Secara default, Amazon MQ mengoptimalkan antrean dengan konsumen cepat:
+ Konsumen dianggap *cepat* jika mereka mampu bersaing dengan laju pesan yang dihasilkan oleh produsen.
+ Konsumen dianggap *lambat* jika antrean menimbulkan backlog pesan yang tidak diakui, berpotensi menyebabkan penurunan throughput produsen.
Untuk menginstruksikan Amazon MQ agar mengoptimalkan antrean dengan konsumen lambat, atur `concurrentStoreAndDispatchQueues` atribut ke `false`. Contoh konfigurasi, lihat [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues).
## Memilih Tipe Instans Broker yang Tepat untuk Throughput Terbaik
Throughput pesan dari [tipe instans broker](broker-instance-types.md) tergantung pada kasus penggunaan aplikasi Anda dan faktor berikut:
+ Penggunaan ActiveMQ dalam mode tetap
+ Ukuran pesan
+ Jumlah produsen dan konsumen
+ Jumlah tujuan
### Memahami hubungan antara ukuran pesan, latensi, dan throughput
Tergantung pada kasus penggunaan Anda, tipe instans broker yang lebih besar mungkin tidak selalu meningkatkan throughput sistem. Ketika ActiveMQ menulis pesan ke penyimpanan tahan lama, ukuran pesan Anda menentukan faktor pembatas sistem:
+ Jika pesan Anda lebih kecil dari 100 KB, latensi penyimpanan tetap adalah faktor pembatas.
+ Jika pesan Anda lebih besar dari 100 KB, throughput penyimpanan tetap adalah faktor pembatas.
Ketika Anda menggunakan ActiveMQ dalam mode tetap, menulis ke penyimpanan biasanya terjadi ketika ada beberapa konsumen atau ketika konsumen lambat. Dalam modus tidak tetap, menulis ke penyimpanan juga terjadi dengan konsumen lambat jika memori tumpukan instans broker penuh.
Untuk menentukan tipe instans broker terbaik bagi aplikasi Anda, kami merekomendasikan pengujian tipe instans broker yang berbeda. Untuk informasi selengkapnya, lihat [Amazon MQ untuk jenis instans broker ActiveMQ](broker-instance-types.md) dan juga [Mengukur Throughput untuk Amazon MQ menggunakan Tolok Ukur JMS](https://aws.amazon.com/blogs/compute/measuring-the-throughput-for-amazon-mq-using-the-jms-benchmark/).
### Kasus penggunaan untuk jenis instans broker yang lebih besar
Ada tiga kasus penggunaan umum ketika tipe instans broker yang lebih besar meningkatkan throughput:
+ **Mode tidak tetap** – Ketika aplikasi Anda kurang sensitif terhadap kehilangan pesan selama [failover instans broker](amazon-mq-broker-architecture.md#active-standby-broker-deployment) (misalnya, ketika menyiarkan skor olahraga), Anda mungkin sering menggunakan mode tidak tetap ActiveMQ. Dalam mode ini, ActiveMQ menulis pesan ke penyimpanan tetap hanya jika memori tumpukan instans broker penuh. Sistem yang menggunakan mode tidak tetap bisa mendapatkan manfaat dari jumlah memori yang lebih tinggi, CPU yang lebih cepat, dan jaringan yang lebih cepat dan tersedia pada tipe instans broker yang lebih besar.
+ **Konsumen cepat** – Ketika konsumen aktif tersedia dan bendera [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues) diaktifkan, ActiveMQ memungkinkan pesan mengalir langsung dari produsen ke konsumen tanpa mengirim pesan ke penyimpanan (bahkan dalam mode tetap). Jika aplikasi Anda dapat mengonsumsi pesan dengan cepat (atau jika Anda dapat merancang konsumen Anda untuk melakukan hal ini), aplikasi bisa mendapatkan keuntungan dari tipe instans broker yang lebih besar. Untuk membiarkan aplikasi Anda mengonsumsi pesan lebih cepat, tambahkan utas konsumen ke instans aplikasi Anda atau tingkatkan skala instans aplikasi Anda secara vertikal atau horizontal.
+ **Transaksi yang di-batch** – Ketika menggunakan mode tetap dan mengirim beberapa pesan per transaksi, Anda dapat mencapai throughput pesan yang lebih tinggi secara keseluruhan dengan menggunakan tipe instans broker yang lebih besar. Untuk informasi selengkapnya, lihat [Should I Use Transactions?](http://activemq.apache.org/should-i-use-transactions.html) dalam dokumentasi ActiveMQ.
## Pilih jenis penyimpanan broker yang tepat untuk throughput terbaik
Untuk memanfaatkan daya tahan dan replikasi yang tinggi di beberapa Availability Zone, gunakan Amazon EFS. Untuk memanfaatkan latensi rendah dan throughput yang tinggi, gunakan Amazon EBS. Untuk informasi selengkapnya, lihat [Amazon MQ untuk jenis penyimpanan ActiveMQ](broker-storage.md).
## Mengonfigurasi Jaringan Broker dengan Benar
Saat Anda membuat [jaringan broker](network-of-brokers.md), konfigurasikan dengan benar untuk aplikasi Anda:
+ **Aktifkan mode tetap** – Karena (tergantung pada rekannya) setiap instans broker bertindak seperti produsen atau konsumen, jaringan broker tidak menyediakan replikasi terdistribusi dari pesan. Broker pertama yang bertindak sebagai konsumen menerima pesan dan menahannya ke penyimpanan. Broker ini mengirimkan pengakuan kepada produsen dan meneruskan pesan ke broker berikutnya. Ketika broker kedua mengakui ketetapan pesan, broker pertama akan menghapus pesan.
Jika modus tetap dinonaktifkan, broker pertama mengakui produsen tanpa menahan pesan ke penyimpanan. Untuk informasi selengkapnya, lihat [Replicated Message Store](http://activemq.apache.org/replicated-message-store.html) dan [What is the difference between persistent and non-persistent delivery?](http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html) dalam dokumentasi Apache ActiveMQ.
+ **Jangan nonaktifkan pesan penasihat untuk instans broker** – Untuk informasi selengkapnya, lihat [Advisory Message](http://activemq.apache.org/advisory-message.html) dalam dokumentasi Apache ActiveMQ.
+ **Jangan gunakan penemuan broker multicast** – Amazon MQ tidak mendukung penemuan broker menggunakan multicast. Untuk informasi selengkapnya, lihat [What is the difference between discovery, multicast, and zeroconf?](http://activemq.apache.org/multicast-transport-reference.html) dalam dokumentasi Apache ActiveMQ.
## Hindari mulai ulang lambat dengan memulihkan transaksi XA yang disiapkan
ActiveMQ mendukung transaksi terdistribusi (XA). Mengetahui cara ActiveMQ memproses transaksi XA dapat membantu menghindari waktu pemulihan yang lambat untuk mulai ulang dan failover broker di Amazon MQ
Transaksi XA yang disiapkan dan belum terselesaikan akan diputar ulang pada setiap mulai ulang. Jika masih belum terselesaikan, jumlahnya akan bertambah dari waktu ke waktu, secara signifikan meningkatkan waktu yang dibutuhkan untuk memulai broker. Hal ini memengaruhi waktu mulai ulang dan failover. Anda harus menyelesaikan transaksi ini dengan `commit()` atau `rollback()` agar performa tidak menurun seiring waktu.
Untuk memantau transaksi XA yang belum terselesaikan, Anda dapat menggunakan `JournalFilesForFastRecovery` metrik di Amazon CloudWatch Logs. Jika jumlah ini meningkat, atau secara konsisten lebih tinggi dari `1`, Anda harus memulihkan transaksi yang belum terselesaikan dengan kode yang serupa dengan contoh berikut. Untuk informasi selengkapnya, lihat [Kuota di Amazon MQ](amazon-mq-limits.md).
Kode contoh berikut berjalan menelusuri transaksi XA yang disiapkan dan menutupnya dengan `rollback()`.
```
import org.apache.activemq.ActiveMQXAConnectionFactory;
import javax.jms.XAConnection;
import javax.jms.XASession;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
public class RecoverXaTransactions {
private static final ActiveMQXAConnectionFactory ACTIVE_MQ_CONNECTION_FACTORY;
final static String WIRE_LEVEL_ENDPOINT =
"tcp://localhost:61616";;
static {
final String activeMqUsername = "MyUsername123";
final String activeMqPassword = "MyPassword456";
ACTIVE_MQ_CONNECTION_FACTORY = new ActiveMQXAConnectionFactory(activeMqUsername, activeMqPassword, WIRE_LEVEL_ENDPOINT);
ACTIVE_MQ_CONNECTION_FACTORY.setUserName(activeMqUsername);
ACTIVE_MQ_CONNECTION_FACTORY.setPassword(activeMqPassword);
}
public static void main(String[] args) {
try {
final XAConnection connection = ACTIVE_MQ_CONNECTION_FACTORY.createXAConnection();
XASession xaSession = connection.createXASession();
XAResource xaRes = xaSession.getXAResource();
for (Xid id : xaRes.recover(XAResource.TMENDRSCAN)) {
xaRes.rollback(id);
}
connection.close();
} catch (Exception e) {
}
}
}
```
Dalam skenario dunia nyata, Anda dapat memeriksa transaksi XA yang disiapkan pada Manajer Transaksi XA. Kemudian Anda dapat memutuskan apakah akan menangani setiap transaksi yang disiapkan dengan `rollback()` atau `commit()`.