Sahn Lam
@sahnlam • 48,880 subscribers
Coauthor of the Bestselling 'System Design Interview' Series | Cofounder at ByteByteGo | YouTube: https://t.co/IphBm2DLnZ
Videos
Git Merge vs. Rebase vs. Squash Commit What are the differences and when should you use each? As I explain in more detail in the video, there are some key distinctions. Git Merge This creates a new commit in the target branch. The new commit ties the histories of both main and feature branches together. Git merge is non-destructive - it introduces a new commit without altering existing ones. Git Rebase Rebase transplants commits to the tip of another branch. It creates new commits for each one moved over. The benefit is linear history. But be cautious with shared branches to avoid confusing collaborators. Squash Commit Squashing condenses multiple commits into one, streamlining the commit history. Watch the video to see when to use merge vs rebase vs squash when incorporating changes between main and feature branches. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages):
Sahn Lam65,160 Aufrufe • vor 2 Jahren
Why is Redis Fast? Redis is fast for in-memory data storage. Its speed has made it popular for caching, session storage, and real-time analytics. But what gives Redis its blazing speed? Let's explore: RAM-Based Storage At its core, Redis primarily uses main memory for storing data. Accessing data from RAM is orders of magnitude faster than from disk. This is a major reason for Redis's speed. However, RAM is volatile. To persist data, Redis supports disk snapshots and append-only file logging. This combines RAM's performance with disk's permanence. There is a tradeoff though - recovery from disk is slow. If a Redis instance fails, restarting from disk can be slow compared to failing over to a replica instance fully in memory. So while Redis offers durability via disk, it comes at the cost of slower recovery. A better solution is Redis replication. With a synchronized replica kept in memory, failover is instant with no rehydration. This maintains speed and near-instant recovery. IO Multiplexing & Single-threaded Read/Write Redis uses an event-driven, single-threaded model for its core operations. A main event loop handles all client requests and data operations sequentially. This single-threaded execution avoids context switching and synchronization overhead typical of multi-threaded systems. Redis uses non-blocking I/O to handle multiple connections asynchronously. This allows it to support many client connections with very low overhead, Redis does leverage threading in certain areas: - Background tasks like taking snapshots. - I/O threads are used for certain operations. - Modules can use threads. - Since Redis 6.0, it supports multi-threaded I/O for network communication, improving performance on multi-core systems. Redis also uses pipelining for high throughput. Clients pipeline commands without waiting for each response. This allows more efficient network round trips, boosting overall performance. Efficient Data Structures Redis supports various optimized data structures, from linked lists, zip lists, and skip lists to sets, hashes, and sorted sets, among others. Each is carefully designed for specific use cases for quick and efficient data access. Over to you: With Redis now supporting some multi-threading, how should we configure it to fully utilize all the CPU cores of modern hardware when deploying in production? – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages):
Sahn Lam46,910 Aufrufe • vor 2 Jahren
Consistent Hashing Explained Simply Let's break down consistent hashing in a way that's easy to get. It's a handy technique for distributing data evenly across servers. And if you're more of a visual learner, don't miss the attached video which brings this concept to life. Here's how it works: We don't just hash our data keys; we also hash the server names using the same method. This puts everything on a scale, known as the hash space, which we think of as a big circular ring. So, imagine we've got a few servers. We hash them and place them on this ring. We do the same with our data, hashing it by key. To figure out where to store a piece of data, we travel clockwise on the ring from where the data lands until we bump into a server. Like, data key 0 might end up on server 0, and key 1 on server 1. Adding a new server? Only the data near the new server needs to shift. And if a server has to go? Only the data it was holding needs a new spot. But there's a little challenge: sometimes, data doesn't spread out evenly. The fix? Virtual nodes. They're like mini-replicas of a server placed around the ring. The more virtual nodes we have, the better the balance. But there's a catch: more virtual nodes mean more memory usage for tracking them, and it can make the whole system a bit more complex to manage. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages):
Sahn Lam36,787 Aufrufe • vor 2 Jahren
Keine weiteren Inhalte verfügbar