Update README.md
Xiang Li
parent
6ef625faec
commit
57bb8bf3f5
45
README.md
45
README.md
|
|
@ -14,7 +14,7 @@ This will bring up a node, which will be listening on internal port 7001 (for se
|
|||
|
||||
#### Setting the value to a key
|
||||
|
||||
Let’s set the first key-value pair to the node. In this case our key is “/message” and our value is “Hello world”.
|
||||
Let’s set the first key-value pair to the node. In this case the key is `/message` and the value is `Hello world`.
|
||||
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/keys/message -d value="Hello world"
|
||||
|
|
@ -25,16 +25,16 @@ curl http://127.0.0.1:4001/v1/keys/message -d value="Hello world"
|
|||
```
|
||||
|
||||
This response contains five fields. We will introduce three more fields as we try more commands.
|
||||
1. The action of the request; we set the value via a post request, thus the action is “SET”
|
||||
1. The action of the request; we set the value via a POST request, thus the action is `SET`.
|
||||
|
||||
2. The key of the request; we set “/message” to “Hello world!”, so the key field is “/message”.
|
||||
Notice we use a file system like structure to represent the key-value pairs. So each key starts with “/”.
|
||||
2. The key of the request; we set `/message` to `Hello world!`, so the key field is `/message`.
|
||||
Notice we use a file system like structure to represent the key-value pairs. So each key starts with `/`.
|
||||
|
||||
3. The current value of the key; we set the value to “Hello world!”.
|
||||
3. The current value of the key; we set the value to`Hello world`.
|
||||
|
||||
4. If we set a new key; “/message” did not exist before, so this is a new key.
|
||||
4. If we set a new key; `/message` did not exist before, so this is a new key.
|
||||
|
||||
5. Index field is the unique request index of the set request. Each sensitive request we send to the server will have a unique request index. The current sensitive request are “SET”, “DELETE” and “TESTANDSET”. All of these request will change the state of the key-value store system, thus they are sensitive. “GET”, “LIST” and “WATCH” are non-sensitive commands. Those commands will not change the state of the key-value store system.
|
||||
5. Index field is the unique request index of the set request. Each sensitive request we send to the server will have a unique request index. The current sensitive request are `SET`, `DELETE` and `TESTANDSET`. All of these request will change the state of the key-value store system, thus they are sensitive. `GET`, `LIST` and `WATCH` are non-sensitive commands. Those commands will not change the state of the key-value store system.
|
||||
You may notice that in this example the index is 3, although it is the first request you sent to the server. This is because there are some internal commands that also change the state of the server, we also need to assign them command indexes(Command used to add a server and sync the servers).
|
||||
|
||||
#### Getting the value of a key
|
||||
|
|
@ -44,11 +44,12 @@ curl http://127.0.0.1:4001/v1/keys/message
|
|||
```
|
||||
|
||||
You should receive the response as
|
||||
```json
|
||||
{"action":"GET","key":"/message","value":"Hello world","index":3}
|
||||
|
||||
```
|
||||
#### Changing the value of a key
|
||||
|
||||
We change the value of “/message” from “Hello world” to “Hello etcd”
|
||||
We change the value of `/message` from `Hello world` to `Hello etcd`
|
||||
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/keys/message -d value="Hello etcd"
|
||||
|
|
@ -112,9 +113,9 @@ In one terminal, we send a watch request:
|
|||
curl http://127.0.0.1:4001/v1/watch/foo
|
||||
```
|
||||
|
||||
Now, we are watching at the path prefix “/foo” and wait for any changes under this path.
|
||||
Now, we are watching at the path prefix `/foo` and wait for any changes under this path.
|
||||
|
||||
In another terminal, we set a key “/foo/foo” to “barbar” to see what will happen:
|
||||
In another terminal, we set a key `/foo/foo` to `barbar` to see what will happen:
|
||||
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/keys/foo/foo -d value=barbar
|
||||
|
|
@ -138,19 +139,19 @@ You should see the watch command return immediately with the same response as pr
|
|||
|
||||
#### Trying TestAndSet
|
||||
|
||||
Etcd servers will process all the command in sequence atomically, thus it can be used as a centralized decision making cluster.
|
||||
Etcd servers will process all the command in sequence atomically, thus it can be used as a centralized decision making cluster.
|
||||
|
||||
TestAndSet is the most basic operation to build distributed lock service and more interesting stuff.
|
||||
|
||||
What it does is to test whether the given previous value is equal to the value of the key, if equal etcd will change the value of the key to the given value.
|
||||
|
||||
Here is a simple example.
|
||||
Let us create a key first. testAndSet=one
|
||||
Let us create a key-value pair first: `testAndSet=one`.
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/keys/testAndSet -d value=one
|
||||
```
|
||||
|
||||
Let us try this
|
||||
Let us try a invaild `TestAndSet` command.
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/testAndSet/testAndSet -d prevValue=two -d value=three
|
||||
```
|
||||
|
|
@ -162,9 +163,9 @@ The response should be
|
|||
Test one==two fails
|
||||
```
|
||||
|
||||
which means testAndSet fails.
|
||||
which means `testAndSet` failed.
|
||||
|
||||
Let try again
|
||||
Let us try a vaild one.
|
||||
|
||||
```sh
|
||||
curl http://127.0.0.1:4001/v1/testAndSet/testAndSet -d prevValue=one -d value=two
|
||||
|
|
@ -184,9 +185,9 @@ Last we provide a simple List command to list all the keys under a prefix path.
|
|||
|
||||
Let us create some keys first.
|
||||
|
||||
We already have /foo/foo=barbar
|
||||
We already have `/foo/foo=barbar`
|
||||
|
||||
We create another one /foo/foo_dir/foo=barbarbar
|
||||
We create another one `/foo/foo_dir/foo=barbarbar`
|
||||
|
||||
```sh
|
||||
http://127.0.0.1:4001/v1/keys/foo/foo_dir/bar -d value=barbarbar
|
||||
|
|
@ -201,16 +202,18 @@ curl http://127.0.0.1:4001/v1/list/foo/
|
|||
We should see the response as
|
||||
|
||||
```json
|
||||
{"Key":"foo","Value":"barbar","Type":"f"},{"Key":"foo_dir","Value":".","Type":"d"},
|
||||
{"Key":"foo","Value":"barbar","Type":"f"} {"Key":"foo_dir","Value":".","Type":"d"}
|
||||
```
|
||||
|
||||
which meas foo is a key under /foo and the value is “barbar” and a key foo_dir is a directory.
|
||||
which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a directory.
|
||||
|
||||
### Setting up a cluster of three machines
|
||||
Next we can explore the power of etcd cluster. We use go-raft as the underlay distributed protocol which provide consistency and persistence of all the machines in the cluster. The will allow if the minor machine dies, the cluster will still be able to performance correctly. Also if most of the machines dead and restart, we will recover from the previous state of the cluster.
|
||||
|
||||
Let us create 3 new machines.
|
||||
|
||||
The first one will be
|
||||
|
||||
We use -s to specify server port and -c to specify client port and -d to specify the directory to store the log and info of the node in the cluster
|
||||
|
||||
```sh
|
||||
|
|
@ -261,7 +264,7 @@ OK. Next let us kill all the nodes to test persistence. And restart all the node
|
|||
|
||||
Try
|
||||
```sh
|
||||
curl http://127.0.0.1:4002/v1/keys/foo again.
|
||||
curl http://127.0.0.1:4002/v1/keys/foo
|
||||
```
|
||||
You should able to see
|
||||
```json
|
||||
|
|
|
|||
Loading…
Reference in New Issue