How does the game server kick out an invalid tcaproxy (access layer) node?
TcaplusDB API supports disaster recovery in case of any tcaproxy exceptions. There are two main ways in which the API kicks out invalid tcaproxy processes:
1. The API physically considers that a tcaproxy is not available. The API sends heartbeat detection packets to all connected tcaproxy every second. If a game server does not receive the corresponding heartbeat return packets from tcaproxy within 10 seconds, the API will actively disconnect the TCP connection to the tcaproxy and actively connect the tcaproxy at the next onupdate.
2. API logically considers that a tcaproxy is not available. It calculates the request and response ratio of a tcaproxy every 10 seconds as a basis for judgment. The time out threshold for the API to a request packet is 3s. If it times out more than 3 times, the tcaproxy is considered unavailable and the request will not be sent to the tcaproxy. A getmetdata request is sent after 60s. If tcaproxy can correctly handle the getmetadata request , the API considers the tcaproxy available and the request is sent to the tcaproxy again.
If the game server finds that a tcaproxy is not available within 10s, it will not send data to the tcaproxy node.
How does the game server choose the tcaproxy (access layer) node?
The gameserver maintains a consistent Hash ring locally. Once a tcaproxy (access layer) node has been verified, it will be added to the Hash ring. If a tcaproxy (access layer) node reduces capacity or the TCP link between gameserver and tcaproxy (access layer) has been disconnected due to machine abnormalities, the gameserver will remove the tcaproxy (access layer) node from the Hash ring. The gameserver calculates hash values based on the primary key in the request (if it is a batchget request, it randomly selects a single tcaproxy (access layer) node), and then selects a single tcaproxy (access layer) node to send out on the consistent Hash ring.
Does TcaplusDB have the compression feature?
TcaplusDB has a compression feature using Google's Snappy compression algorithm. It includes protocol compression, i.e., compressing request/response packets between the game server and tcaproxy (access layer); and data compression, i.e., compressing data when storing it in tcapsvr (storage layer). If you want to save network traffic between the game server and tcaproxy, it is recommended to enable protocol compression using the SetCompressSwitch function in the TcaplusDB API. Enabling compression in the tcapsvr (storage layer) is also recommended to save disk space and improve disk IO performance. The CPU overhead for compression and decompression is manageable.
Is the TcaplusDB API thread-safe?
TcaplusDB API is non-thread-safe, mainly because components such as tlog and tdr are not thread-safe. It is recommended that a single thread uses a single API object and a single game region uses a single API object. If you need to interact across game regions, it is recommended to maintain multiple API objects with a single game server.
How does tcaproxy (access layer) achieve disaster recovery?
Tcaproxy (access layer) adopts a peer-to-peer design scheme, that is, all tcaproxy (access layer) nodes under a single game region contain routing information of all tables under a single game region. If a tcaproxy (access layer) fails, as long as the remaining tcaproxy (access layer) nodes are not overloaded, the game server will kick out the abnormal tcaproxy (access layer) node, which will not affect the use of game server. There is no single point of failure risk for the tcaproxy (access layer).
How does tcapsvr (storage layer) achieve disaster recovery?
The tcapsvr (storage layer) runs in a primary-secondary mode (primary tcapsvr and secondary tcapsvr). Primary and secondary tcapsvr synchronize data in real time, and are deployed at the different IDCs in the same city, ensuring that primary-secondary synchronization latency is less than 10 ms. If the secondary tcapsvr is abnormal, it will not affect the use of game server (if the read request offloading is not enabled, the requests of game server are processed by the primary tcapsvr. If the read request offloading is enabled, the secondary tcapsvr will assist in processing part of the read requests), and the DBA will rebuild the secondary tcapsvr; if the primary tcapsvr is abnormal, the secondary tcapsvr will perform failure recovery and the DBA will apply for a new machine to rebuild the secondary tcapsvr. There is no single point of failure risk for the tcapsvr (storage layer).
Does TcaplusDB have overload protection?
Both the access layer and the storage layer have process-level overload protection measures to ensure that services will not collapse during peak hours.
What is the principle of cold and hot data exchange for TcaplusDB?
TcaplusDB uses memory + SSD disk storage, a single engine file, and the first 1 GB is mapped in memory. The hot data is placed in the memory, the cold data is placed on the disk, and the LRU algorithm is used for hot and cold data exchange. The get operation of gameserver triggers the LRU swap-in operation. The LRU thread of tcapsvr (storage layer) is responsible for the LRU swap-out operation. Try to ensure that the hot data is stored in the memory, thus ensuring high cache hit rate and low single read and write latency.
How does tcaproxy (access layer) choose tcapsvr (storage layer)?
Each table defines a sub-table factor. If no sub-table is defined, the sub-table factor defaults to the primary key. Tcaproxy (access layer) selects the corresponding tcapsvr (storage layer) according to hash (sub-table factor) %1w, so the dispersion of the sub-table factor needs to be high.
What is the level of the lock in TcaplusDB?
The granularity of the lock in TcaplusDB is logging level.
If the number of shards is too large or too small, will it affect the performance of CRUD operations and engine tuning in TcaplusDB?
The impact is negligible. Online large tables are divided into at least hundreds of shards.
What factors are considered for the number of shards in a business?
Generally considered: Each shard has 1GB in memory, with about 500MB storing the Key and 300MB storing the Value. Having as many Keys in memory as possible can improve performance. Increasing the shard size to a maximum of 256GB per shard can affect recovery operations if the file is too large.
Does Tcaplus face penetration issues with high-frequency data reads?
Tcaplus has overload protection. When penetration causes service overload, some requests will be rejected at the access layer.
If a large number of requests flood in suddenly, will there be a queuing mechanism for tcaproxy and tcapsvr?
Yes, there will be a queuing mechanism. Exceeding the processing capacity will cause large latency and timeouts. For tcaproxy, it is related to the number of request connections and will distribute connections to the proxy for processing. For tcapsvr, it depends on whether the request data is dispersed. If concentrated on a few shards or keys, there will be queuing.
Traversal principle
Tcaplus supports full table traversal operations for GENERIC and LIST tables. It will initiate traversal tasks on each tcapsvr where the table is distributed based on sharding logic. Therefore, the overall traversal request performance is relatively low. It is recommended to set the traversal data to be read from the tcapsvr slave, which will not affect the services provided by the tcapsvr master, using the SetOnlyReadFromSlave(bool flag) interface.
If the data to be fetched each time is not much, consider first whether the local index can meet the requirements.
Once the traversal iterator starts, Tcaplus's tcapsvr will initiate an internal iterator to traverse and read the node data on the tree based on time slices. It finds the key first, then the value, and packages the traversed data into the buffer, returning it to the service API. The internal traversal logic of the service API will determine whether there is packet loss or duplicate packets based on whether the expected seq matches the received seq. Once it is confirmed that the received packets are as expected, the main thread can get a complete package when calling RecvResponse and then can parse a business record by calling FetchRecord. Traversal can be interrupted and terminated at any time and can be conditionally recovered. Overall, traversal within the service API adopts a ping-pong automatic trigger mechanism. After receiving the expected packet, it will automatically decide whether to initiate the next traversal request (e.g., if the backend storage server clearly returns a BUSY error, the traversal will be interrupted) until the traversal is clearly completed or the business stops the traversal.