79 lines
4.9 KiB
Markdown
79 lines
4.9 KiB
Markdown
# messengerbroker
|
|
|
|
[](https://paypal.me/emsicz) [](https://github.com/masiton?tab=repositories)
|
|
|
|
An add-on service for [messengerapi](https://gitea.masita.net/mc/messengerapi) that adds inter-broker capability, making messengerapi resilient against outage by giving clients additional messengerapi URLs to query against if main URL becomes inop. Runs as sidecar container with it's own DB, and periodically syncs messengerapi databases between different instances.
|
|
|
|
__Messenger Broker is in alpha. It is discouraged to rely on it in production environment.__
|
|
|
|
# Why
|
|
|
|
Running single instance of message broker mean clients are left with no communication if the instance goes down for any reason at all. Adding secondary, or even tertiary instance of messenger to provide fallback option for clients is desirable. Broker runs in the background as a synchronizer of Messenger API databases. Messenger itself is completely unaware of this, while Broker keeps track of what entities injected into Messenger's database are foreign.
|
|
|
|
# How
|
|
|
|
Broker runs 3 tasks endlessly for each server it's supposed to provide resiliency for:
|
|
|
|
- User and UserRoute synchronization periodically (typically every 1 minute).
|
|
- Message synchronization (fast) - endless queries to provide all messages for last short period of time (typically last 10 seconds).
|
|
- Message synchronization (slow) - endless queries to provide all messages for entire visible history of garbage collection. This process runs typically every 10 minutes and serves to collect missed updates, deliveries, and acknowledgements.
|
|
|
|
To prevent clogging, Broker will only provide 1000 records per request, so synchronizing Broker has to provide a time argument for where to start the lookup. You can see this [here](https://gitea.masita.net/mc/messengerapi.Broker/src/commit/908774c5aabcf7eb6eeeb52a8fa7262d8a537a3b/code/MessengerBroker/Handlers/MasterServerSynchronizationHandler.cs#L82).
|
|
|
|
## Auth
|
|
|
|
Broker uses it's own unique Broker ID to authenticate itself and others. All exposed endpoints expect this ID to be sent over as part Bearer token in Authorization header. Each Broker is configured for a list of servers that are expected to pull, and list of server that the Broker itself is supposed to pull from. Bearer token is then compared against that list during each call to make sure only allowed Brokers consume resources.
|
|
|
|
## Setup
|
|
|
|
Mandatory tunables are super-simple:
|
|
|
|
- `SQL_CONNECTIONSTRING`
|
|
- Must be provided. This is Broker's own database.
|
|
- _Example: `"Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=192.168.1.2"`_
|
|
|
|
- `API_SQL_CONNECTIONSTRING`
|
|
- Must be provided. This is access to MessengerApi's instance database that the broker will manage.
|
|
- _Example: `"Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=192.168.1.2"`_
|
|
|
|
- `BROKER_ID`
|
|
- Must be provided. This identifies broker's against each other.
|
|
- _Example: `15D97720-F5B7-47AA-9C1A-71F98B0B9248`_
|
|
|
|
- `MASTER_SERVERS`
|
|
- Must be provided, if this instance provides fallback for another instance. Individual server info is separated by semicolon, but data related to the server are separated by comma as `BrokerId1,BrokerUrl1,BrokerName1;BrokerId2,BrokerUrl2,BrokerName2`, etc.
|
|
- _Example: `F696442B-E8DC-4074-B34F-94BCECE8E74B,http://localhost:1234,test1;D1B65834-53BA-45F8-A1E1-66C91C7CFCA9,http://localhost:5678,test2`_
|
|
|
|
- `SLAVE_SERVERS`
|
|
- Must be provided, if this instance wants to share data to another instance for fallback purposes. Same logic applies as for `MASTER_SERVERS`, except `SLAVE_SERVERS` do not require `BrokerUrl`, so the mask is as follows: `BrokerId1,BrokerName1;BrokerId2,BrokerName2`, etc.
|
|
- _Example: `20E4B747-EC58-4071-8AD9-25521F3C4013,test3`_
|
|
|
|
### PostgreSQL
|
|
|
|
To run broker's db against postgres, omit the `SQL_CONNECTIONSTRING` and use this:
|
|
|
|
- `PERSISTENCE_TYPE: PostgreSql`
|
|
- This tells broker to use PostgreSql DB Context.
|
|
- `NPG_CONNECTIONSTRING`
|
|
- Must be provided.
|
|
- _Example: `"Host=localhost;Port=5432;Database=myDatabase;Username=postgres;Password=********`_
|
|
|
|
If messenger also runs against postgres, the logic is similar:
|
|
|
|
- `API_PERSISTENCE_TYPE: PostgreSql`
|
|
- `API_NPG_CONNECTIONSTRING`
|
|
|
|
Additional tunables, with their sustainable default values:
|
|
|
|
- `HOUSEKEEPING_ENABLED: true`
|
|
- Periodically runs housekeeping to remove obsolete messages. Uses `HOUSEKEEPING_MESSAGE_AGE_IN_MINUTES` to identify what to delete. This housekeeping job only pertains to broker's DB, it doesn't remove any messages from the messenger itself, as messenger has it's own housekeeping job.
|
|
- `HOUSEKEEPING_MESSAGE_AGE_IN_MINUTES: 180`
|
|
- If a message synchronized by broker is older than set value, it is removed from broker's DB.
|
|
|
|
# Endpoints
|
|
|
|
Endpoints listed here are consumed by other Brokers.
|
|
|
|
## `GET /users`
|
|
|