Computer >> Hướng Dẫn Máy Tính >  >> Lập Trình >> Redis

Tại sao di chuyển từ Dynomite sang Redis Enterprise Active‑Active mang lại Performance và Reliability vượt trội

Kể từ khi ra đời 2009, Redis OSS có community open source rất vibrant. Nhiều tools và utilities phát triển xung quanh nó và Dynomite, một peer-to-peer geo-distribution layer cho non-distributed datastores, là một trong số đó.

Dynomite được develop bởi team engineer tại Netflix và release as open source. Mặc dù cung cấp good solutions cho specific needs, nó không được effectively maintained trong vài năm gần đây. Hơn nữa, một số functionality, commands, và data types của Redis OSS (ví dụ Pub/Sub hoặc Streams) bị unavailable hoặc limited bởi distribution model của Dynomite cho Redis OSS instances.

Vì lý do này, chúng tôi giúp tổ chức migrate Dynomite databases sang Redis Enterprise cluster.

So sánh kiến trúc Dynomite và Redis Enterprise

Bắt đầu so sánh với quick description kiến trúc cả hai.

Dynomite

Typical Dynomite cluster mô tả như sau:

  • Trải rộng multiple data centers

  • Single datacenter là group of racks

  • Rack là group of nodes: mỗi rack hold entire dataset, partitioned across multiple nodes in that rack

Tại sao di chuyển từ Dynomite sang Redis Enterprise Active‑Active mang lại Performance và Reliability vượt trội

Dynomite là peer-to-peer distribution layer, do đó client có thể send write traffic đến bất kỳ node nào trong Dynomite cluster. Nếu node responsible for data, data written to local Redis OSS server process, then asynchronously replicated to other racks in cluster across all data centers. Nếu node không own data, nó act as coordinator send write đến node owning data trong same rack. Nó cũng replicate writes đến corresponding nodes trong other racks và DCs.

Redis Enterprise

Redis Enterprise cluster cũng distribute data across different Redis instances, hoặc shards, nhưng có hai main differences:

  • Có thể hơn một shard trên một node – nhưng primary và replica không thể sống trên same node, cho high availability purposes.

  • Chỉ có một replica cho mỗi primary shard. Client perform data operations trên primary shards. Replica của chúng exist cho high availability trong case failure của primary shards.

Phần quan trọng khác của Redis Enterprise cluster gọi là "management path;" bao gồm Cluster Manager, Proxy, và REST API/UI. Cluster Manager responsible orchestrating cluster, placing database shards in highly-available nodes, detecting failures. Proxy hide cluster topology của Redis Enterprise từ applications bằng cách cung cấp single, never-changing endpoint cho mỗi database trong cluster. Nó cũng giúp scale client connections bằng multiplexing và pipelining commands đến shards.

Illustration typical Redis Enterprise Cluster:

Tại sao di chuyển từ Dynomite sang Redis Enterprise Active‑Active mang lại Performance và Reliability vượt trội

Với Active-Active feature của Redis Enterprise, bạn tạo global database span multiple clusters. Những clusters typically reside in different data centers around the world. Application write đến Active-Active database connect đến local instance endpoint. Tất cả writes bởi application đến local instance replicated đến all other instances với strong eventual consistency.

Active-Active replication cung cấp nhiều advantages as geo-distributed solution, một trong đó là seamless conflict resolution cho simple và complex Redis Enterprise data types, chúng ta sẽ discuss dưới.

Bây giờ có idea về topologies của Dynomite và Redis Enterprise, hãy xem chúng entail gì cho developers và DevOps trong tổ chức.

Dynomite hay Redis Enterprise: Sự khác biệt gì cho Developers?

Bên cạnh Dynomite không actively maintained, có ba main reasons tổ chức muốn migrate sang Redis Enterprise từ developer perspective:

  • Redis functionalities limited và more complex khi dùng Dynomite

  • Dynomite không có effective way deal với geo-distributed write conflicts

  • Support bạn nhận được từ Redis

Xem chi tiết hai lý do đầu.

Redis OSS Limited và Complex

Như bạn đã biết, Redis OSS không phải plain key-value store, nghĩa là không chỉ associate string keys đến string values. Redis OSS là data structures server supporting different kinds of values: lists, sets, hashes, streams. Chúng ta gọi đó "core data types" của Redis OSS.

Redis OSS cũng extensible through dynamic libraries gọi là "modules". Modules cho phép rapidly implement new Redis commands với features similar to what can be done inside core. Popular modules: RediSearch (querying, secondary indexing, full-text search), RedisJSON (turn Redis OSS thành powerful document store).

Như discussed in introduction, một số Redis OSS commands và data types bị unavailable hoặc limited bởi Dynomite. Non-exhaustive comparison:

Tại sao di chuyển từ Dynomite sang Redis Enterprise Active‑Active mang lại Performance và Reliability vượt trội

Complete list supported/unsupported commands with Dynomite tại đây.

Ngược lại, Redis Enterprise, maintained alongside Redis OSS, cho phép multi-model operations dùng modules và core Redis OSS data structures executed fully programmable và distributed manner.

Absence of Conflict Resolution (Thiếu giải quyết xung đột)

Dynomite là AP system và gives three options cho consistency. Dù chọn option nào, important aware rằng Dynomite resolve asynchronous write conflicts bằng Last Write Wins strategy. Điều này lead to lost updates do irrelevant timestamps, especially trong context geo-distributed writes.

Ngược lại, Active-Active architecture của Redis Enterprise based on alternative implementation của Redis OSS commands và data types gọi là Conflict-Free-Replicated-Data-Types (CRDTs). CRDTs dùng vector clocks cho event ordering. Chúng ensure khi any two replicas received same set of updates, chúng reach same state, deterministically, bằng mathematically sound rules guarantee state convergence. Ngoài ra, có thể enable causal consistency.

Do đó với Redis Enterprise:

  • Outcome của concurrent writes predictable và based on set of rules

  • Applications không cần bother với concurrent writes và resolution write conflicts

  • Dataset eventually converge đến single, consistent state

Nếu bạn up for it, tìm rules implemented và examples conflict resolution tại link này.

Dynomite hay Redis Enterprise: Sự khác biệt gì cho DevOps?

Bây giờ so sánh Dynomite và Redis Enterprise từ DevOps perspective, discuss topics:

  • High Availability

  • Scalability

  • Deployability

High Availability

Khi node fail trong Dynomite rack, writing và reading đến rack trở nên impossible. Nghĩa là application writing locally cần handle failover đến rack khác by itself. Note: nếu application developed in Java, Netflix's Dyno client có thể handle failovers đến remote racks khi local Dynomite node fail.

Hơn nữa, khi node comes back up, data written trên remote racks trong failure sẽ missing từ failed node. Nếu deploy trong AWS autoscaling groups, dùng Netflix's Dynomite Manager, làm node replacement và node warm-up trong AWS auto-scaling group.

Redis Enterprise high availability như thế nào?

Khi node fail, single-digit-seconds failover xảy ra cho all primary shards living on that node, replicas promoted to primaries. Auto-failover mechanism guarantee data served với minimal interruption.

Dựa trên này:

  • Redis Enterprise Proxy ensure single-endpoint database không change in case failover, no reconfiguration application needed.

  • Có option "replica_ha" ensure khi replica promoted to primary, new synced replica shard created automatically trên any other available nodes.

Mechanisms này allow Redis Enterprise guarantee 99.99% uptime và 99.999% uptime cho Active-Active deployments.

Scalability

Dynomite allow scale Redis OSS maintaining good performance latency. Check benchmarks nhưng nếu dùng Dynomite bạn probably already know that.

Về scalability, main differences giữa Dynomite và Redis Enterprise:

  • Manageability

  • Out-of-the box connection management

  • Resource optimization

Manageability

Nếu không dùng Dynomite Manager trong AWS autoscaling group, thêm hosts vào running Dynomite rack typically requires:

  • Leverage "dual writes" technique dùng Java Dyno client; application write vào old/small cluster và new/scaled one. Sau vài ngày, route traffic chỉ đến new cluster làm active.

  • Migrate database từ old/small cluster sang new/scaled one

Ngược lại, Redis Enterprise allow bạn:

  • Scale up bằng add shards to database without adding nodes to cluster: Useful khi enough under-utilized capacity in cluster. Remember: one node không equal one Redis instance. Resharding database done in few clicks qua Redis Enterprise UI, hoặc leverage Redis Enterprise's REST API. Done without downtime hoặc service interruption. Transparent to application vì database endpoint không change.

  • Scale out bằng add node(s) to cluster. Useful nếu more physical resources needed để add shards to database. Note: với Redis Enterprise Cloud (fully-managed DBaaS), tổ chức không need worry about step này. Redis sẽ provision và manage infrastructure và resources. Xem thêm Deployment section.

Benchmark Redis làm vài năm trước, Redis Enterprise delivered over 200 million ops/sec, sub-millisecond latency, trên 40 AWS instances.

Connection management

Khi nói connection management với Redis, first comes to mind là Redis clients như Jedis hoặc Lettuce handle connection pooling và pipelining. Netflix no exception và implemented these features cho Dyno client.

Redis Enterprise cung cấp such features out-of-the-box. Proxy itself establish persistent connections đến shards in cluster, connections shared by clients. Nó cũng apply performance optimizations bằng scheduling requests on number of persistent connections đến shards, doing multiplexing và pipelining on Redis side.

Plus, proxy multi-threaded và automatically scale handle bursts in client connections.

Resource optimization

Thứ nhất, nhớ rằng within Redis Enterprise cluster one machine không equal one Redis instance và each primary shard chỉ có up to one replica.

Thứ hai, Redis Enterprise multi-tenant. Nghĩa là single Redis Enterprise cluster serve hundreds of completely isolated databases. Far from trivial dùng Dynomite. Worth noting Redis Enterprise multi-tenancy fits well với multi-model capabilities. Trong context microservices, imagine running different fit-for-purpose databases in single set of nodes, each với own replication, scaling, persistence, module configuration.

Cuối cùng, Redis Enterprise có feature Redis On Flash (RoF). RoF enable databases use cả RAM và dedicated flash memory (SSD/NVMe) handle much larger datasets với RAM-like latency và performance, nhưng at >70% lower cost compared to all-RAM database.

Deployment options

Dynomite deploy in containers hoặc machines running Ubuntu, RHEL, CentOS. Deployments always self-managed, nghĩa là bạn provide infrastructure và resources manage cluster. Hơn nữa, nếu muốn tận dụng Dynomite Manager features, cần deploy Dynomite trong AWS autoscaling group.

Ngược lại, Redis Enterprise có nhiều deployment options, chia thành hai groups:

  • Self-managed solutions: download, install, deploy Redis Enterprise Software yourself. Lots of options: Linux installers (multiple distributions), Amazon Machine Image (AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS).

  • Managed solutions: Redis Enterprise Cloud offered as fully managed cloud service (DBaaS) on all three major public cloud platforms (Google Cloud, AWS, Azure). Redis host dedicated environment cho bạn, với necessary resources, tạo databases với private và public endpoints cho applications consume.