From Tencent, based on RocksDB as persistent storage. Binlog to support resuming transport when running replication.
2. Kvrocks
Apache project, poor document. Have seen no advantage over Tendis so far. Also based on RocksDB.
3. KeyDB
Redis fork, multi-threading adopted.
4. Codis
A Redis proxy, clients are not required to know the cluster protocol.
5. redis-cluster-proxy
A Redis proxy, clients are not required to know the cluster protocol.
6. RedisShake
Redis data synchronization(Cross DC). Launch multiple process if sync source is a cluster setup. Used for one-shot full sync scenario, not recommanded for long-time incremental sync.
– C: libevent seems to give best performance, but also low level.
– C++: drogon has websocket support, but no sse. async.
– C++: poco is sync.
– C++: workflow is low level, hard to use. wfrest has convenient apis, sse support in trunk.
– C++: boost/beast has poor performance, and cannot utilize multi-core cpu.
– C++: oatpp is async, but complex framework.
– Better use high level languages like Java or Go if running a web application.
Read documents of Apache shardingsphere several years ago, and used to think it is the best database sharding library in client side. After trying to use it in a real-world application, problems reveal. First, the ecosystem has grown so large. Even a demo spring boot application can reference lots of dependencies. Second, when loading large data set from multiple shards, multi-threading is not used. I still have to manually implement it myself to improve load time.
Actually, what I need is the ability for selecting a database shard implicitly. When I write select t_user from..., it is rewritten to select t_user[0-7] from.... Here’s some alternative options I found:
v2ray unblocks github access from mainland China. Install v2ray clients and set IE proxy _only_ on Windows, bootstrap.bat & vcpkg.exe picks it automatically.
Export vcpkg-2022.08.15 directory as ${VCPKG_ROOT}.
3. Install drogon framework for demo
The drogon framework is a high performance application framework, including client & server supports. vcpkg builds static(*.a) library by default, use x64-linux-dynamic for dynamic(*.so) library. The repo version requires g++-8 to build, install from CentOS SCL:
It sticks to drogon 1.8.0 and openssl 1.1.1n. ${VCPKG_ROOT} now required to be a git repository. In your project directory, install specific versions of libraries by running:
The only difference is the existence of vcpkg.json file, when using versioning.
7. Binary caching
If you change the root path of vcpkg, better clean up the cache, or build may fail. It’s $HOME/.cache/vcpkg/archives under Linux, and %LOCALAPPDATA%\vcpkg\archives under Windows.
Just got time to investigate and summarize them. Actually I started from the Microservices book, it introduced Saga & transactional outbox pattern. The sample code is too complex, abstracted too well, and hard to trace. After finished reading the book, I still have no option about how to deploy disturbed transactions to my services, without the author’s framework. And many details are messed up for me. For instance, what’s the difference between Saga, TCC & XA? How to handle partial failures? What if it fails in rollback/cancel phase? How about the latency of Saga? the consistency? I cannot find the precise answer, it is just a book for students, not for engineers.
I investigated several frameworks:
1. Seata
Seata/Alibaba is the most famous one. It runs in XA, Saga, TCC, and an additional AT(Auto Transaction?) mode. AT mode is actually an application-level XA, which is business-agnostic. Seata manages and generates rollback SQLs for you, but there are limitations. I am most interested in TCC, which is easy to understand, and is the most complete solution to distributed transactions. Also, it requires most effort to implement. From the recent release notes, there are still fundamental bugs, and documents are hard to read, which make me wonder its usability.
2. Hmily
Hmily(How Much I Love You)/JD is the second one, since it’s in Java. From the point of an end user, it very easy to integrate. It provides annotations to simplify TCC implementation. But one critical design bug(via quick scan of its code): It saves its transaction logs asynchronously via disruptor, which makes it much easier to lost transactions and lead to an inconsistent status.
3. DTM
dtm/(Bytedance? Tencent?) should be one with most potentialities so far. It clears most of my uncertainty. It has most informative documents, and helps me to choose between all distributed transaction modes. When talking about consistency: XA > TCC > 2-phase message > Saga. And Saga is most useful in long transactions.
One innovation(and patent?): it introduced subtransaction barriers. The mechanism perfectly handles repeated request, dangling action, dangling compensation in TCC automatically, without user attention.
And the only drawback is: it is written in golang(I even learned go programming meanwhile). Hopefully, it provides lightweight restful APIs.
4. ByteCC
ByteCC. Not investigated. Seems not actively maintained.
5. EasyTransaction
EasyTransaction. Not investigated, here is a review(In Chinese) from the author.