solution: docs for access logging

This commit is contained in:
Igor Artamonov
2021-07-19 23:15:31 -04:00
parent 3a12efd0a0
commit e8fc025966
11 changed files with 141 additions and 25 deletions

View File

@@ -29,7 +29,7 @@ And for a request:
- Is it for concrete data (_block #100_) or the latest (_get balance_)?
- Is result a static value (_just block_) or may vary depending on network and node (_latest nonce_)?
- Does it need to be repeated over multiple nodes (_broadcast transaction_)?
- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "link:08-quorum-and-selectors.adoc[Quorum and Selectors]")
- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "link:09-quorum-and-selectors.adoc[Quorum and Selectors]")
Based on these factors, Dshackle executes the request on a most optimal node.
For most of the simple requests, it just gets a node that is synchronized to the point that must have a response for that particular request.
@@ -43,7 +43,7 @@ It provides:
- Routes only realy/alive upstreams, i.e., synchronized and with enough peers
- Load Balancing
- Request Retry on upstream errors
- Local Caching (memory and Redis, see link:09-caching.adoc[Caching])
- Local Caching (memory and Redis, see link:10-caching.adoc[Caching])
- Broadcasting and Quorum for requests
=== gRPC protocol