Rumah > Operasi dan penyelenggaraan > operasi dan penyelenggaraan linux > Pengalaman Redis yang perlu anda ketahui untuk operasi dan penyelenggaraan Linux

Pengalaman Redis yang perlu anda ketahui untuk operasi dan penyelenggaraan Linux

Lepaskan: 2023-08-04 16:17:11
ke hadapan
1008 orang telah melayarinya

Redis sangat popular dalam komuniti teknologi semasa. Redis telah berjalan jauh dari projek peribadi kecil dari Antirez hingga menjadi standard industri untuk penyimpanan data dalam memori. Set amalan terbaik yang terhasil membolehkan kebanyakan orang menggunakan Redis dengan betul.

Di bawah ini kami akan meneroka 10 pengalaman menggunakan Redis dengan betul.

1 Berhenti menggunakan KEYS *

Baiklah, memulakan artikel ini dengan mencabar arahan ini mungkin bukan cara yang baik, tetapi ia mungkin perkara yang paling penting. Banyak kali apabila kita memberi perhatian kepada statistik contoh redis, kita akan dengan cepat memasukkan arahan "KEYS *" supaya maklumat utama akan dipaparkan dengan jelas. Untuk bersikap adil, dari perspektif pengaturcaraan, kami cenderung untuk menulis pseudokod seperti berikut:

for key in'keys *':
doAllTheThings() 
Salin selepas log masuk

Tetapi apabila anda mempunyai 13 juta kekunci, kelajuan pelaksanaan akan menjadi perlahan. Oleh kerana kerumitan masa perintah KEYS ialah O(n), dengan n ialah bilangan kekunci yang akan dikembalikan, kerumitan arahan ini bergantung pada saiz pangkalan data. Dan semasa pelaksanaan operasi ini, tiada arahan lain boleh dilaksanakan dalam contoh anda.

Sebagai arahan alternatif, lihat SCAN, yang membolehkan anda melakukannya dengan cara yang lebih mesra pengguna... SCAN mengimbas pangkalan data dalam lelaran tambahan. Operasi ini dilakukan berdasarkan lelaran kursor, jadi anda boleh berhenti atau meneruskan pada bila-bila masa yang anda rasa patut.

2. Ketahui punca yang melambatkan Redis

Memandangkan Redis tidak mempunyai log yang sangat terperinci, adalah sangat sukar untuk mengetahui perkara yang dilakukan di dalam instance Redis. Mujurlah, Redis menyediakan alat statistik arahan seperti berikut:

127.0.0.1:6379> INFO commandstats

# Commandstats

cmdstat_get:calls=78,usec=608,usec_per_call=7.79

cmdstat_setex:calls=5,usec=71,usec_per_call=14.20

cmdstat_keys:calls=2,usec=42,usec_per_call=21.00

cmdstat_info:calls=10,usec=1931,usec_per_call=193.10
Salin selepas log masuk

Melalui alat ini, anda boleh melihat petikan semua statistik arahan, seperti berapa kali arahan telah dilaksanakan dan bilangan milisaat yang diperlukan untuk melaksanakan perintah (jumlah masa bagi setiap arahan dan masa purata) hanya laksanakan arahan CONFIG RESETSTAT untuk menetapkan semula supaya anda boleh mendapatkan keputusan statistik yang baharu sepenuhnya.

3、将 Redis-Benchmark 结果作为参考,而不要一概而论

Redis 之父 Salvatore 就说过:“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里,他们想知道为什么自己的Redis-Benchmark统计的结果低于最优结果 。但我们必须要把各种不同的真实情况考虑进来,例如:

  • 可能受到哪些客户端运行环境的限制?
  • 是同一个版本号吗?
  • 测试环境中的表现与应用将要运行的环境是否一致?

Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点,但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式,并且需要一个尽可能的和生产相似的环境。

4、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构:

foo:first_name

foo:last_name

foo:address
Salin selepas log masuk

上面的例子中,foo 可能是一个用户的用户名,其中的每一项都是一个单独的 key。这就增加了 犯错的空间,和一些不必要的 key。使用 hash 代替吧,你会惊奇地发现竟然只需要一个 key :

127.0.0.1:6379> HSET foo first_name 'Joe'

(integer) 1

127.0.0.1:6379> HSET foo last_name 'Engel'

(integer) 1

127.0.0.1:6379> HSET foo address '1 Fanatical Pl'

(integer) 1

127.0.0.1:6379> HGETALL foo

1) 'first_name'

2) 'Joe'

3) 'last_name'

4) 'Engel'

5) 'address'

6) '1 Fanatical Pl'

127.0.0.1:6379> HGET foo first_name

'Joe'
Salin selepas log masuk

5、设置 key 值的存活时间

无论什么时候,只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候,设成同样的超时时间,Redis就会自动为你清除!而不再需要使用KEYS *来遍历所有的key了,怎么样很方便吧?

6. Pilih strategi kitar semula yang sesuai

Sekarang kita telah bercakap tentang topik pembersihan kunci, mari kita bercakap tentang strategi kitar semula. Apabila ruang contoh Redis diisi, ia akan cuba menuntut semula beberapa kunci. Bergantung pada penggunaan anda, saya amat mengesyorkan menggunakan strategi volatile-lru - dengan syarat anda telah menetapkan tamat masa pada kunci. Tetapi jika anda menjalankan sesuatu yang serupa dengan cache dan tidak menetapkan mekanisme tamat masa untuk kunci, anda boleh mempertimbangkan untuk menggunakan mekanisme kitar semula allkeys-lru. Cadangan saya adalah untuk melihat apa yang mungkin di sini dahulu.

7 Jika data anda penting, sila gunakan Try/Except

Jika anda mesti memastikan data kritikal boleh dimasukkan ke dalam contoh Redis, saya amat mengesyorkan meletakkannya dalam blok try/except. Hampir semua pelanggan Redis menggunakan strategi "hantar dan lupakan", jadi selalunya perlu untuk mempertimbangkan sama ada kunci sebenarnya diletakkan dalam pangkalan data Redis. Kerumitan meletakkan cuba/harapkan ke dalam arahan Redis bukanlah maksud artikel ini. Anda hanya perlu tahu bahawa berbuat demikian memastikan data penting diletakkan di tempat yang sepatutnya.

8. Jangan kehabisan instance

Bila boleh, sebarkan beban kerja berbilang kejadian redis. Bermula dari versi 3.0.0, Redis menyokong kelompok. Kluster Redis membolehkan anda memisahkan beberapa kekunci yang mengandungi mod induk/hamba berdasarkan julat kekunci. "Keajaiban" lengkap di sebalik pengelompokan boleh didapati di sini. Tetapi jika anda sedang mencari tutorial, ini adalah tempat yang sesuai. Jika pengelompokan bukan pilihan, pertimbangkan ruang nama dan sebarkan kunci anda merentas berbilang kejadian. Mengenai cara mengedarkan data, terdapat ulasan hebat ini di laman web redis.io.

9 Adakah lebih banyak teras lebih baik? !

Sudah tentu ia salah. Redis ialah proses satu-benang dan hanya menggunakan maksimum dua teras walaupun dengan kegigihan didayakan. Melainkan anda bercadang untuk menjalankan berbilang kejadian pada satu hos - semoga hanya dalam persekitaran pembangunan dan ujian! ——Jika tidak, tidak perlu lebih daripada 2 teras untuk contoh Redis.

10. Ketersediaan tinggi

Setakat ini, Redis Sentinel telah diuji secara menyeluruh, dan ramai pengguna telah menerapkannya pada persekitaran pengeluaran (termasuk ObjectRocket). Jika aplikasi anda sangat bergantung pada Redis, anda perlu menghasilkan penyelesaian ketersediaan tinggi untuk memastikan ia tidak pergi ke luar talian. Sudah tentu, jika anda tidak mahu menguruskan perkara ini sendiri, ObjectRocket menyediakan platform ketersediaan tinggi dan sokongan teknikal 7×24 jam Jika anda berminat, anda boleh mempertimbangkannya.

Atas ialah kandungan terperinci Pengalaman Redis yang perlu anda ketahui untuk operasi dan penyelenggaraan Linux. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Label berkaitan:
sumber:Linux中文社区
Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan