-
Notifications
You must be signed in to change notification settings - Fork 0
Project3
Single-Server In-Memory Key-Value Server (no need to submit design doc)
The system has an in-sync stage where both servers are in sync; note that the backup server always enters the in-sync stage earlier than primary server.
All key/values are stored in memory using a concurrent data structure smiliar to map[string]string , with automatic read/write locking.
Primary server has four possible stages:
- Cold start
- Bootstrapping Secondary
- Warm Start
- In Sync
###Cold Start Upon a cold start, the primary server check for the existence of backup server; if none exist, the primary server will enter bootstrapping stage with empty data.
If there exists a backup server already, then primary server enters the warm start stage and let backup enter bootstrapping stage.
During this stage, the server refuses all query.
###Bootstrapping Secondary This stage will wait for a backup server to be started (and listen), then transfer all data to the backup; if the backup server properly acknowledged, the server enters in sync; if any failure happens, the primary server wait for some timeout, and then start over the bootstrapping.
During this stage, the server only respond to read-only queries and rejects all write query.
To comply with the project requirement, the primary server will not attempt to launch the backup server by itself, and will just wait patiently.
###Warm Start The primary server will fetch all data from secondary server; after success (a mutual acknowledgement and integrity checksum), the server enters in sync after secondary server is in sync stage; if failed, restart the warm start.
During this stage, the server rejects all write query, all not-yet existent read queries, and use the partially-complete database to response to some read queries (with confidence that the response is correct).
###In Sync The server response to all read requests naturally; upon receiving a write request:
- The server will update it locally,
- Send the update to secondary server, and wait for acknowledgement;
- Respond success after backup server response;
- If backup server fails or timed out, then rewind this update, response with failure, try to kill the backup and then enters Bootstrapping Secondary stage.
During this stage, the server accepts all queries regularly.
Backup server has four possible stages:
- Cold start
- Bootstrapping Primary
- Warm Start
- In Sync
Note that the backup server can decide its initial state by parameters; by default, we enter cold start.
###Cold Start Upon a cold start, the backup server check the existence of a primary server. If so, enters warm start stage; otherwise enters warm-start stage.
###Bootstrapping Primary The backup server listen to primary; if the primary server comes, the backup server will reply with a copy of current database.
The backup server can compute an integrity hash function (checksum) for the database; if the primary has successfully fetched the data and replied with the correct checksum, then the secondary acknowledge and enters in sync; otherwise reply with failure and let the primary start over.
To comply with the project requirement, the backup server will not attempt to launch the primary server, and will just wait patiently.
###Warm Start The backup server will listen to primary server for incoming data, and then recover a copy of database. After finished, the primary should send a checksum, and the secondary will acknowledge (and enters in sync) if the checksum is matched. If not matched, the secondary will reply failure and listen again.
###In Sync The backup server listens to primary server for updates, saves them to local database and replies acknowledgement.
The backup server periodically checks the existence of primary server; if primary is offline for some reason, the backup can kick itself to bootstrapping stage.
(talk to backup... timeout)
(only receive upsert commands; ignore key already exist or not)
Go JSON library github streamrail/concurrent-map