- vừa được xem lúc

[Redis] - Quản lý DB và Key

0 0 9

Người đăng: TheLight

Theo Viblo Asia

Quản lý database

Redis hỗ trợ 16 database logic trong một Redis server. Các database này được tách biệt với nhau một cách hiệu quả và khi chúng ta chạy một lệnh trong một database , nó không ảnh hưởng đến bất kỳ dữ liệu nào được lưu trữ trong các database khác trong Redis server của chúng ta.

Database Redis được đánh số từ 0 đến 15 và theo mặc định, chúng ta kết nối với database 0 khi chúng ta kết nối với Redis server. Tuy nhiên, chúng ta có thể thay đổi database đang sử dụng bằng lệnh select sau khi kết nối:

> select 15

Để swap tất cả dữ liệu được giữ trong một database với dữ liệu được giữ trong một database khác ta sử dụng lệnh swapdb . Ví dụ sau sẽ swap dữ liệu được giữ trong database 6 với dữ liệu trong database 8 và bất kỳ client nào được kết nối với một trong hai database sẽ có thể thấy các thay đổi ngay lập tức:

> swapdb 6 8

Lệnh swapdb sẽ trả về OK nếu swap thành công.

Nếu chúng ta muốn di chuyển một key sang một datatabse Redis khác, chúng ta có thể chạy lệnh migrate. Lệnh này đảm bảo key tồn tại trên database redis đích đến trước khi xóa nó khỏi database redis nguồn. Khi chúng ta chạy migrate, lệnh phải bao gồm các phần tử sau theo thứ tự này:

  • Tên server hoặc địa chỉ IP của database đích
  • Port của database đích
  • Tên của key chúng ta muốn di chuyển
  • Số thứ tự database (từ 0 đến 15) nơi chúng ta muốn lưu key trên database đích đến
  • Thời gian chờ, tính bằng mili giây, xác định lượng thời gian giao tiếp không tải tối đa giữa hai máy. Lưu ý đây không phải là giới hạn thời gian cho hoạt động.

Ví dụ

> migrate 203.0.113.0 6379 key_1 7 8000

Ngoài ra, lệnh migrate cho phép các tùy chọn sau mà chúng ta có thể thêm sau đối số thời gian chờ:

  • COPY : Chỉ định rằng key không được xóa khỏi database nguồn
  • REPLACE : Chỉ định rằng nếu key đã tồn tại trên database đích, hoạt động migrate sẽ xóa và thay thế nó.
  • KEYS : Thay vì cung cấp một key cụ thể để di chuyển, chúng ta có thể nhập một chuỗi trống ( "" ) và sau đó sử dụng cú pháp từ lệnh keys để di chuyển bất kỳ key nào phù hợp với một mẫu.

Quản lý các key

Có một số lệnh Redis hữu ích để quản lý các key.

Lệnh rename sẽ đổi tên key được chỉ định. Nếu thành công, nó sẽ trả về OK :

> rename old_key new_key

Chúng ta có thể sử dụng randomkey để trả về một key ngẫu nhiên từ database hiện đang được chọn:

> randomkey
Output
"any_key"

Sử dụng lệnh type để xác định loại dữ liệu mà key đã cho nắm giữ. Đầu ra của lệnh này có thể là string , list , hash , set , zset hoặc stream :

> type key_1
Output
"string"

Nếu key được chỉ định không tồn tại, lệnh này sẽ trả về none.

Chúng ta có thể di chuyển một private key lẻ sang database khác trong Redis server của chúng ta bằng lệnh move . move lấy tên của một key và số thứ tự database nơi chúng ta muốn di chuyển key làm đối số. Ví dụ: để di chuyển key key_1 sang database 8 , chúng ta sẽ chạy như sau:

> move key_1 8

move sẽ trả về OK nếu di chuyển key thành công.

Xóa các key

Để xóa một hoặc nhiều key của bất kỳ kiểu dữ liệu nào ta sử dụng lệnh del theo sau là một hoặc nhiều key mà chúng ta muốn xóa:

> del key_1 key_2

Nếu lệnh này xóa (các) key thành công, nó sẽ trả về (integer) 1 . Nếu không, nó sẽ trả về (integer) 0 .

Lệnh unlink thực hiện một chức năng tương tự như del , với sự khác biệt là del sẽ chặn client kết nối khi mà server đang lấy lại bộ nhớ được chiếm bởi key. Nếu key đang bị xóa được liên kết với một lượng nhỏ dữ liệu, lượng thời gian để del lấy lại bộ nhớ là rất nhỏ và thời gian chặn thậm chí có thể không đáng chú ý.

Tuy nhiên, nó có thể trở nên bất tiện nếu chẳng hạn, key chúng ta đang xóa được liên kết với nhiều dữ liệu, chẳng hạn như một hàm băm với hàng nghìn hoặc hàng triệu trường. Việc xóa key như vậy có thể mất một thời gian đáng kể và chúng ta sẽ bị chặn thực hiện bất kỳ thao tác nào khác cho đến khi nó bị xóa hoàn toàn khỏi bộ nhớ của server .

Tuy nhiên trước khi sử dụng lệnh unlink , trước tiên xác định chi phí của việc phân bổ bộ nhớ mà key chiếm dụng. Nếu key chiếm dụng bộ nhớ nhỏ thì unlink hoạt động giống như cách del làm đó là ngay lập tức chặn client . Tuy nhiên, key chiếm dụng bộ nhớ lớn, việc unlink sẽ xóa key không đồng bộ bằng cách tạo một stream khác và dần dần lấy lại bộ nhớ trong background mà không chặn client :

> unlink key_1

Vì nó chạy ở chế độ nền, nên thường chúng ta nên sử dụng unlink để xóa key khỏi server của chúng ta nhằm giảm lỗi trên client của chúng ta, mặc dù trong nhiều trường hợp lệnh del cũng sẽ đủ dùng.

Cảnh báo: Hai lệnh sau được coi là nguy hiểm. Các flushdbflushall sẽ xóa tất cả các key trong một database và tất cả các key trong mọi database trên server Redis một cách không phục hồi được . Chúng ta chỉ nên chạy các lệnh này nếu chúng ta hoàn toàn chắc chắn rằng chúng ta muốn xóa tất cả các key trong database hoặc server của chúng ta .

Chúng ta có thể đổi tên các lệnh nguy hiểm để phòng tránh chạy nhầm các lệnh này.

Để xóa tất cả các key trong database đã chọn, hãy sử dụng lệnh flushdb :

> flushdb

Để xóa tất cả các key trong mọi database trên server Redis (bao gồm cả database hiện được chọn), hãy chạy flushall :

> flushall

Cả flushdbflushall chấp nhận tùy chọn async , cho phép chúng ta xóa tất cả các key trên một database duy nhất hoặc mọi database trong cụm một cách không đồng bộ. Điều này cho phép chúng hoạt động tương tự như lệnh unlink và chúng sẽ tạo một stream mới để giải phóng dần bộ nhớ trong background.

Backup database của chúng ta

Để tạo bản backup của database hiện được chọn, chúng ta có thể sử dụng lệnh save :

> save

Thao tác này sẽ xuất một ảnh chụp nhanh của tập dữ liệu hiện tại dưới dạng file .rdb , là file kết xuất database chứa dữ liệu ở định dạng tuần tự hóa nén nội bộ.

save chạy đồng bộ và sẽ chặn bất kỳ kế nối nào từ client kết nối với database. Tài liệu về lệnh save khuyến nghị rằng lệnh này hầu như không bao giờ được chạy trong môi trường production . Thay vào đó nên sử dụng lệnh bgsave. Điều này yêu cầu Redis phân tách database : cấp độ root sẽ tiếp tục phục vụ các client trong khi tiến trình con lưu database trước khi thoát:

> bgsave

Lưu ý nếu client thêm hoặc sửa đổi dữ liệu trong khi hoạt động bgsave đang diễn ra, những thay đổi này sẽ không được ghi lại trong ảnh chụp nhanh dữ liệu backup.

Chúng ta cũng có thể chỉnh sửa file cấu hình Redis để Redis tự động lưu ảnh chụp nhanh (được gọi là chế độ chụp nhanh hoặc RDB ) sau một khoảng thời gian nhất định nếu một số thay đổi tối thiểu được thực hiện đối với database . Đây được coi là một điểm lưu. Các cài đặt điểm lưu sau được bật theo mặc định trong file /etc/redis/redis.conf :

. . .
save 900 1
save 300 10
save 60 10000
. . .
dbfilename "nextfile.rdb"
. . .

Với các cài đặt này, Redis sẽ xuất một ảnh chụp nhanh backup của database sang file được xác định bởi tham số dbfilename cứ sau 900 giây nếu có ít nhất 1 key được thay đổi, cứ sau 300 giây nếu có ít nhất 10 key được thay đổi và cứ sau 60 giây nếu ít nhất 10000 key được thay đổi.

Chúng ta có thể sử dụng lệnh shutdown để backup dữ liệu Redis của chúng ta và sau đó đóng kết nối. Lệnh này sẽ chặn mọi client kết nối với database và sau đó thực hiện thao tác save nếu ít nhất một điểm lưu được cấu hình, nghĩa là nó sẽ backup database ở trạng thái hiện tại sang file .rdb trong khi ngăn client thực hiện bất kỳ thay đổi nào.

Ngoài ra, lệnh shutdown sẽ xóa các thay đổi đối với file chỉ phần phụ của Redis trước khi thoát nếu chế độ chỉ phần bổ sung được bật. Chế độ file chỉ nối thêm (AOF) liên quan đến việc tạo log của mọi hoạt động ghi trên server trong file kết thúc bằng .aof sau mỗi ảnh chụp nhanh. Chế độ AOF và RDB có thể được bật trên cùng một server và sử dụng cả hai phương pháp liên tục là một cách hiệu quả để backup dữ liệu .

Nói tóm lại, lệnh shutdown về cơ bản là một lệnh save chặn kết nối của client và cũng xóa tất cả các thay đổi gần đây đối với file chỉ nối thêm và đóng kết nối với Redis:

Cảnh báo: Lệnh shutdown được coi là nguy hiểm . Bằng cách chặn các client của server Redis, chúng ta có thể làm cho dữ liệu của chúng ta không khả dụng đối với user và ứng dụng phụ thuộc vào nó. Chúng ta chỉ nên chạy lệnh này nếu chúng ta đang kiểm tra hành vi của Redis hoặc chúng ta hoàn toàn chắc chắn rằng chúng ta muốn chặn tất cả các client trên server Redis của chúng ta .

Chúng ta có thể đổi tên lệnh này thành một tên khác gợi ý rằng lệnh nguy hiểm để phòng ngừa rủi do chạy lệnh này.

> shutdown

Nếu chúng ta chưa cấu hình bất kỳ điểm lưu nào nhưng vẫn muốn Redis thực hiện thao tác save , hãy thêm tùy chọn save vào lệnh shutdown này:

> shutdown save

Nếu chúng ta đã cấu hình ít nhất một điểm lưu nhưng chúng ta muốn tắt server Redis mà không thực hiện lưu, chúng ta có thể thêm đối số nosave vào lệnh:

> shutdown nosave

Lưu ý file chỉ dành cho phần phụ thêm có thể dài ra theo thời gian, nhưng chúng ta có thể cấu hình Redis để viết lại file dựa trên các biến nhất định bằng cách chỉnh sửa file redis.conf. Chúng ta cũng có thể hướng dẫn Redis viết lại file chỉ dành cho phần thêm bằng cách chạy lệnh bgrewriteaof :

> bgrewriteaof

bgrewriteaof sẽ tạo bộ lệnh ngắn nhất cần thiết để đưa database trở lại trạng thái hiện tại. Như tên của lệnh này, nó sẽ chạy ở chế độ nền. Tuy nhiên, nếu một lệnh duy trì khác đang chạy trong một tiến trình , lệnh đó phải kết thúc trước khi Redis thực thi bgrewriteaof .

Nguồn: https://galaxyz.net/cach-quan-ly-database-va-khoa-redis.26.anews

Bình luận

Bài viết tương tự

- vừa được xem lúc

Caching đại pháp 2: Cache thế nào cho hợp lý?

Caching rất dễ. Mình không nói đùa đâu, caching rất là dễ. Ai cũng có thể làm được chỉ sau 10 phút đọc tutorial. Nó cũng giống như việc đứa trẻ lên 3 đã có thể cầm bút để vẽ vậy.

0 0 114

- vừa được xem lúc

Caching đại pháp 1: Nấc thang lên level của developer

Bí quyết thành công trong việc đáp ứng hệ thống triệu user của những công ty lớn (và cả công ty nhỏ). Tại sao caching lại là kỹ thuật tối quan trọng để phù phép ứng dụng rùa bò của chúng ta thành siêu phẩm vạn người mê.

0 0 67

- vừa được xem lúc

Cache dữ liệu Nodejs với Redis

Một tí gọi là lý thuyết để anh em tham khảo. Cache là gì. Lợi ích của việc cache data. .

0 0 96

- vừa được xem lúc

Nguyên tắc hoạt động của redis server

Sự ra đời của Redis. . Câu chuyện bắt đầu khi tác giả của Redis, Salvatore Sanfilippo. (nickname: antirez), cố gắng làm những công việc gần như là không.

0 0 75

- vừa được xem lúc

Viết ứng dụng chat realtime với Laravel, VueJS, Redis và Socket.IO, Laravel Echo

Xin chào tất cả các bạn, đây là một trong những bài post đầu tiên của mình. Sau bao năm toàn đi đọc các blog tích luỹ được chút kiến thức của các cao nhân trên mạng.

0 0 904

- vừa được xem lúc

Tìm hiểu tổng quan về Redis

1. Lời mở đầu.

0 0 351