Merge branch 'main' into feat-ui-redesign-blog

Signed-off-by: Madelyn Olson <[email protected]>

Author: madolson

.github/workflows/zola-deploy.yml

@@ -40,6 +40,12 @@ jobs:
             repository: valkey-io/valkey-bloom
             path: valkey-bloom
 
+      - name: Checkout valkey-search
+        uses: actions/checkout@v4
+        with:
+            repository: valkey-io/valkey-search
+            path: valkey-search
+
       - name: Checkout valkey-json
         uses: actions/checkout@v4
         with:
@@ -50,7 +56,7 @@ jobs:
         run: |
           cd website
           ./build/init-topics-and-clients.sh ../valkey-doc/topics ../valkey-doc/clients
-          ./build/init-commands.sh ../valkey-doc/commands ../valkey/src/commands ../valkey-bloom/src/commands ../valkey-json/src/commands
+          ./build/init-commands.sh ../valkey-doc/commands ../valkey/src/commands ../valkey-bloom/src/commands ../valkey-json/src/commands ../valkey-search/src/commands
 
       - name: Build only
         uses: shalzz/[email protected]

.gitignore

@@ -13,3 +13,6 @@ _data/groups.json
 _data/resp2_replies.json
 _data/resp3_replies.json
 _data/modules.json
+.vscode/*
+.idea/*
+tmp/*

README.md

@@ -1,7 +1,7 @@
 # Valkey.io website
 
 This repo contains the source for the valkey.io website (build scripts, template, blog posts, stylesheets, etc.).
-The build integrates content from [`valkey-io/valkey-doc`](https://github.com/valkey-io/valkey-doc) and the commands definitions from [`valkey-io/valkey`](https://github.com/valkey-io/valkey), [`valkey-io/valkey-bloom`](https://github.com/valkey-io/valkey-bloom), and [`valkey-io/valkey-json`](https://github.com/valkey-io/valkey-json) (see [Build Locally](#build-locally) below for more details) 
+The build integrates content from [`valkey-io/valkey-doc`](https://github.com/valkey-io/valkey-doc) and the commands definitions from [`valkey-io/valkey`](https://github.com/valkey-io/valkey), [`valkey-io/valkey-bloom`](https://github.com/valkey-io/valkey-bloom), and [`valkey-io/valkey-json`](https://github.com/valkey-io/valkey-json) (see [Build Locally](#build-locally) below for more details)
 
 ## Contributing
 
@@ -29,7 +29,7 @@ Changes to external content (command reference, documentation topics) require a
 ## Building additional content
 
 **By default, the site will build without documentation topics, command reference, or the clients page.**
-The content for documentation topics and the clients page are stored within the `valkey-io/valkey-doc` repo. 
+The content for documentation topics and the clients page are stored within the `valkey-io/valkey-doc` repo.
 The content for the command reference page is in the `valkey-io/valkey` repo.
 
 If you want to build the site with this content, you'll need to have a local copy of `valkey-io/valkey-doc` and `valkey-io/valkey` _outside_ of this repo.
@@ -64,7 +64,8 @@ Commit your changes to your local copy of `valkey-io/valkey-doc`.
 ### Building the command reference
 
 The command reference (i.e. `/commands/set/`, `/commands/get/`, `/commands/lolwut/`) sources information from `valkey-io/valkey`, `valkey-io/valkey-bloom`, and `valkey-io/valkey-doc`.
-`valkey-io/valkey`, `valkey-io/valkey-bloom` and `valkey-io/valkey-json` provides the command metadata (items like computational complexity, version history, arguments, etc) whilst `valkey-io/valkey-doc` provides the command description and the command reply.
+`valkey-io/valkey`, `valkey-io/valkey-bloom`, `valkey-io/valkey-json` and `valkey-io/valkey-search` provides the command metadata (items like computational complexity, version history, arguments, etc)
+whilst `valkey-io/valkey-doc` provides the command description and the command reply.
 
 ```mermaid
 flowchart TD
@@ -75,13 +76,16 @@ flowchart TD
     H --> J[Files: /resp2_replies.json,<br/>/resp3_replies.json] --> Z[Command Reply]
 ```
 
-Let's say that this repo and your local copy of `valkey-io/valkey-doc`, `valkey-io/valkey-bloom`, `valkey-io/valkey-json`, and `valkey-io/valkey` reside in the same directories.
+Let's say that this repo and your local copy of `valkey-io/valkey-doc`, `valkey-io/valkey-bloom`, `valkey-io/valkey-json`, `valkey-io/valkey-search`
+and `valkey-io/valkey` reside in the same directories.
+
 First, stop the `zola serve` process if you're running it.
 From the root directory of this repo run:
 
 ```shell
 # You should only need to run this once or when you add a new command.
-./build/init-commands.sh ../valkey-doc/commands ../valkey/src/commands ../valkey-bloom/src/commands ../valkey-json/src/commands
+./build/init-commands.sh ../valkey-doc/commands ../valkey/src/commands \
+    ../valkey-bloom/src/commands ../valkey-json/src/commands ../valkey-search/src/commands
 ```
 
 Then, restart Zola.

build/init-commands.sh

@@ -4,16 +4,16 @@
 
 # first check to make sure there are arguments
 if [ -z "$1" ]; then
-    echo "You must supply a path to the command docs as the first argument" 
+    echo "You must supply a path to the command docs as the first argument"
     exit 1
-fi 
+fi
 
 if [ -z "$2" ]; then
-    echo "You must supply a path to the command json as the second argument" 
+    echo "You must supply a path to the command json as the second argument"
     exit 1
 fi
 
-# check for validity of these agruments as paths
+# check for validity of these arguments as paths
 if [ ! -d "$1" ]; then
     echo "The command doc directory must exist and be a valid path"
     exit 1
@@ -34,22 +34,31 @@ if [ ! -d "$4" ]; then
     exit 1
 fi
 
+if [ ! -d "$5" ]; then
+    echo "The Search module command JSON directory must exist and be a valid path"
+    exit 1
+fi
+
 ln -s $1 ./build-command-docs
 ln -s $2 ./build-command-json
 ln -s $3 ./build-bloom-command-json
 ln -s $4 ./build-json-command-json
+ln -s $5 ./build-search-command-json
+
 for fname in $(find $1 -maxdepth 1  -iname "*.md")
 do
     base=${fname##*/}
     command=${base%.*}
     command_upper=$(awk '{ print toupper($0) }' <<< $command)
-    if [[ "$command" != "index" ]]; then 
+    if [[ "$command" != "index" ]]; then
         if [ -f "$2/$command.json" ]; then
             metadata_path="/commands/$command.json in the 'valkey' repo"
         elif [ -f "$3/$command.json" ]; then
             metadata_path="/commands/$command.json in the 'valkey-bloom' repo"
         elif [ -f "$4/$command.json" ]; then
             metadata_path="/commands/$command.json in the 'valkey-json' repo"
+        elif [ -f "$5/$command.json" ]; then
+            metadata_path="/commands/$command.json in the 'valkey-search' repo"
         fi
         cat << EOF > "./content/commands/$command.md"
 +++

build/init-topics-and-clients.sh

@@ -4,16 +4,16 @@
 
 # first check to make sure there are arguments
 if [ -z "$1" ]; then
-    echo "You must supply a path to the topics as the first argument" 
+    echo "You must supply a path to the topics as the first argument"
     exit 1
-fi 
+fi
 
 if [ -z "$2" ]; then
-    echo "You must supply a path to the clients directory as the first argument" 
+    echo "You must supply a path to the clients directory as the second argument"
     exit 1
-fi 
+fi
 
-# check for validity of these agruments as paths
+# check for validity of these arguments as paths
 if [ ! -d "$1" ]; then
     echo "The topics directory must exist and be a valid path"
     exit 1

config.toml

@@ -23,6 +23,7 @@ command_description_path = "../build-command-docs/"
 command_json_path = "../build-command-json/"
 command_bloom_json_path = "../build-bloom-command-json/"
 command_json_json_path = "../build-json-command-json/"
+command_search_json_path = "../build-search-command-json/"
 client_json_path = "../build-clients/"
 doc_topic_path = "../build-topics/"
 

content/authors/guowangy.md

@@ -0,0 +1,8 @@
+---
+title: Wangyang Guo
+extra:
+    photo: '/assets/media/authors/guowangy.jpg'
+    github: guowangy
+---
+
+Wangyang Guo is a Software Performance Optimization Engineer at Intel. He specializes in identifying and resolving performance bottlenecks in complex software systems. His contributions include significant performance enhancements to Valkey, the Linux kernel, glibc, and ClickHouse. His expertise spans database systems, low-level system optimization, and scalable distributed applications.

content/authors/lipzhu.md

@@ -0,0 +1,8 @@
+---
+title: Lipeng Zhu
+extra:
+    photo: '/assets/media/authors/lipzhu.jpg'
+    github: lipzhu
+---
+
+Lipeng Zhu is a Software Performance Optimization Engineer at Intel. His contributions to open-source software include performance enhancements for Valkey, the Linux kernel, GCC/libgfortran, and Chromium/libwebp2. His work focuses on identifying and resolving performance bottlenecks through advanced profiling techniques and architectural optimizations specifically designed for modern processor architectures.

content/authors/muhammadawawdi.md

@@ -0,0 +1,8 @@
+---
+title: Muhammad Awawdi
+extra:
+    photo: '/assets/media/authors/muhammadawawdi.jpeg'
+    github: muhammad-awawdi-amazon  
+---
+
+Muhammad is a software engineer at AWS ElastiCache, building Valkey GLIDE and large-scale distributed systems. When he’s not building faster tech, he’s lifting weights, grilling barbecue, or geeking out over the latest innovations.

content/authors/nigel.md

@@ -0,0 +1,8 @@
+---
+title: Nigel Brown
+extra:
+    photo: '/assets/media/authors/nigel.jpg'
+    github: pnbrown
+---
+
+nigel is a Senior Developer Advocate on the Valkey project. He was drawn to the craft of software engineering because of the agency it provides people to build and interact with worlds of their own creation. He focuses on Cloud Native technologies and his passions in technology are community building, High Performance Computing, and free and open source software (and hardware).

content/blog/2024-12-22-az-affinity-strategy.md

@@ -2,7 +2,7 @@
 title= "Reducing application latency and lowering Cloud bill by setting up your client library"
 date= 2025-01-08 01:01:01
 description= "By implementing AZ affinity routing in Valkey and using GLIDE, you can achieve lower latency and cost savings by routing requests to replicas in the same AZ as the client."
-authors= [ "asafporatstoler", "adarovadya"]
+authors= [ "asafporatstoler", "adarovadya", "muhammadawawdi"]
 [extra]
 trending = true
 featured_image = "/assets/media/featured/random-04.webp"
@@ -31,8 +31,9 @@ GLIDE provides flexible options tailored to your application’s needs:
 * ```PRIMARY```: Always read from the primary to ensure the freshness of data.
 * ```PREFER_REPLICA```: Distribute requests among all replicas in a round-robin manner. If no replica is available, fallback to the primary.
 * ```AZ_AFFINITY```: Prioritize replicas in the same AZ as the client. If no replicas are available in the zone, fallback to other replicas or the primary if needed.
+* ```AZ_AFFINITY_REPLICAS_AND_PRIMARY```: Prioritize replicas in the same AZ as the client. If no replicas are available in the zone, fallback to the primary in the same AZ. If neither are available, fallback to other replicas or the primary in other zones.
 
-In Valkey 8,  ```availability-zone``` configuration was introduced, allowing clients to specify the AZ for each Valkey server. GLIDE leverages this new configuration to empower its users with the ability to use AZ Affinity routing. At the time of writing, GLIDE is the only Valkey client library supporting the AZ Affinity strategy, offering a unique advantage.
+In Valkey 8,  ```availability-zone``` configuration was introduced, allowing clients to specify the AZ for each Valkey server. GLIDE leverages this new configuration to empower its users with the ability to use AZ Affinity routing. At the time of writing, GLIDE is the only Valkey client library supporting the AZ Affinity strategies, offering a unique advantage.
 
 ## AZ Affinity routing advantages
 
@@ -43,7 +44,7 @@ In Valkey 8,  ```availability-zone``` configuration was introduced, allowing cli
 
 2. **Minimize Latency** Distance between AZs within the same region— for example, in AWS, is typically up to 60 miles (100 kilometers)—adds extra roundtrip latency, usually in the range of 500µs to 1000µs. By ensuring requests remain within the same AZ, you can reduce latency and improve the responsiveness of your application.
 
-    **Example:**
+    **Example 1:**
     Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client located in az-2 along with replica-1. 
 
     **With ```PREFER_REPLICA``` strategy**:
@@ -56,6 +57,20 @@ In Valkey 8,  ```availability-zone``` configuration was introduced, allowing cli
     In this case, the client will read commands from a replica in the same client's AZ and the average latency is, for example, about 300 microseconds.
 
     ![AZ_AFFINITY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_strategy.png)
+    
+    **Example 2:**
+    Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client located in az-2 along with the primary node. The replicas are located in az-1 and az-3.
+    
+    **With ```AZ_AFFINITY``` strategy**:
+    In this case, the client attempts to read from a replica in the same AZ. Since none are available in az-2, it falls back to a replica in another AZ, such as az-1 or az-3.  
+    and the average latency is, for example, about 800 microseconds.
+    
+    ![AZ_AFFINITY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_strategy2.png)
+
+    **With `AZ_AFFINITY_REPLICAS_AND_PRIMARY` strategy**:  
+    In this case, the client first attempts to read from a replica in the same AZ. Since no local replica exists, it reads from the primary located in az-2. The average latency is, for example, about 300 microseconds.
+
+    ![AZ_AFFINITY_REPLICAS_AND_PRIMARY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_REPLICAS_AND_PRIMARY_strategy.png)
 
 ## Configuring AZ Affinity Connections with GLIDE
 
@@ -155,6 +170,9 @@ Setting up AZ affinity routing in GLIDE is simple, allowing you to leverage its
 ## Conclusion
 By implementing AZ affinity routing in Valkey and using GLIDE, you can achieve lower latency and cost savings by routing requests to replicas in the same AZ as the client.
 
+---
+*Updated May 2025 to cover the `AZ_AFFINITY_REPLICAS_AND_PRIMARY` strategy and a corresponding example.*
+
 ### Further Reading
 * [Valkey GLIDE GitHub Repository](https://github.com/valkey-io/valkey-glide)
 * [Valkey Documentation](https://valkey.io/)