finally after the canonical 1 year of developments, Redis 4.0.0 is out.
I'm very happy about 4.0, because this release finally overcomes
several very important limits of Redis. There are many things in the
4.2 plan, so Redis with 4.0 is not magically perfect. Yet it is a very
important, measurable, step forward, because of the following
features:
1) PSYNC2, the new replication engine. The way the replication
handshake and changes propagation happens between masters and slaves
was significantly changed. Now slaves promoted to masters are able to
accept the old slaves (reconfigured to point to the new master)
without the need to do a full resynchronization. Similarly slaves can
be stopped, upgraded and restarted, and can continue with the master
with just a partial resynchronization. People that run Redis
operations will appreciate this change...
2) Redis modules: finally it is possible to use Redis as a framework
to write networked services without reinventing everything from
scratch. Modules can extend Redis with new functionalities and data
structures, implement types which are exactly like the native types
(persisted in the RDB, rewritten in the AOF, ...), and there is
experimental support for blocking and threaded slow operations.
3) Redis is a better cache with 4.0, because it supports LFU other
than LRU as eviction algorithm, and in general the eviction algorithm
was improved in different ways.
4) DEL, FLUSHDB and FLUSHALL can now be ran in a different thread
calling UNLINK (instead of DEL), and using the ASYNC option of FLUSH
commands. This, together with the new SWAPDB command, open interesting
possibilities to atomically switch a given dataset to another one,
makes certain workloads using only DEL as O(N) commands a lot less
latency sensitive, and can improve also replication setup times,
because the slave, if configured to do so, can delete the old dataset
in background after a full resync.
5) It is now possible to enable a new AOF mode that rewrites the AOF
in terms of an RDB preamble + an AOF tail: faster rewrites, faster
reloads of the data, less latency issues.
6) The Raspberry Pi is now one a supported platform: every new Redis
release is tested on the Pi, the code was audited and fixed for
unaligned accesses, stack traces are supported on ARM.
7) The new MEMORY command, and especially MEMORY DOCTOR, allows to
have a better observability on the Redis memory usage. MEMORY USAGE
can precisely report a key memory utilization.
8) Redis Cluster was improved (but 4.2 will focus mostly on Cluster...
so the big news are headed): NAT/Containers support, better failure
detection (much lower traffic in big clusters), less CPU overhead in
cluster nodes compared to Redis 3.2.
9) Active memory defragmentation. Redis is able to defragment the
memory while online if the Jemalloc allocator is used (the default on
Linux). Useful for workloads where the allocator cannot keep the
fragmentation low enough, so the only possibility is for Redis and the
allocator to collaborate in order to defragment the memory.
A big thank you to the Redis community, providing help in issues, help
channels, fixing documentation, finding bugs, sending PRs. This Redis
release is surely the one that benefitted the most from external help.
A special thank you to my colleagues at Redis Labs that supported me
in all the possible ways, helped me in the hardest moments (see
Heisenbugs...), and that were extremely active in using, testing,
fixing and designing with me the modules API.
Please report 4.0.0 problems ASAP if you find any, I expect a few
patch releases coming before we actually reach the same level of
stability of Redis 3.2.
Enjoy!
Salvatore
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.