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.
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()
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.
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
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.
Redis 之父 Salvatore 就说过:“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里,他们想知道为什么自己的Redis-Benchmark统计的结果低于最优结果 。但我们必须要把各种不同的真实情况考虑进来,例如:
Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点,但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式,并且需要一个尽可能的和生产相似的环境。
以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构:
foo:first_name foo:last_name foo:address
上面的例子中,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'
无论什么时候,只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候,设成同样的超时时间,Redis就会自动为你清除!而不再需要使用KEYS *
来遍历所有的key了,怎么样很方便吧?
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.
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.
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.
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.
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!