缓存算是各个网站、服务的标配了，如何才能设计出一套切合实际需求的缓存方案，每个接触过缓存的Coder脑子里都会有自己的答案。
**缓存模块从无到有，要如何设计？
要考虑哪些因素？
如何方式设计不足？
如何防止设计过度？
如何满足实际需求？
要明确哪些问题，才能逐步的完善出一套实现方案？**
小弟才疏学浅，希望哪位高人能提点一二，不胜感激。
================都焦了，不如割了吧=====================
我的需求：
快，一些记录后就不会变（很少变），但每次都用的信息，每次读DB开销太大。
（Redis的掌握水平只有初级，后面会抓时间恶补）
自己设计：
0、要考虑到 缓存超时、命中率，按需求，逐级增加缓存级别；
1、（一级缓存）第一期，做本地内存级别的缓存，直接从内存中读取，如果没有，再读DB，同时更新缓存对象（DB中用View来提高查询速度）；
2、（二级缓存）第二期，后期RQ增加到一定量，会需要Load Balance，此时会考虑使用Redis或Memcache方案作为二级缓存；当一级缓存未中，则读取二级缓存，扔未中，则查询数据库（将存在的数据，反向全部更新）
问题：
1、如果记录到DB中，配置参数不是单纯的key-value形式，也有查询匹配工作；并且随着业务复杂度提升，还会有其他数据需要缓存。
2、如果记录到NoSQL/Redis中，如Redis，其数据存储，是不是只能用于“灾备”，还是可以使用Redis的数据存储，抛弃DB
3、对Redis的写操作，能否直接记录到存储上？ 因为那些需要缓存的数据，有些是需要手动录入的。
担忧：
第二期时，设计一级、二级缓存是否多余？主要是考虑 读取Redis中的缓存信息会涉及到网络传输
方案：
A、使用一级、二级缓存方案，但分布式部署后，一级缓存中的数据是否超时无法准确判断；
B、放弃一级缓存，直接读取Redis（不知道读取Redis的开销与直接读内存的开销，哪个高。而且一级不命中，再去二级中读，反而绕远）
自问自答：
放弃方案A，因为，虽然直接读本地内存，效率高，但是命中率不好说；
使用方案B，虽然有了网络传输的损耗，但后续的第三期、第四期。。甚至会需要Redis配置主从或分片，这时之前所担心的网络损耗根本不算什么。
以上就是 我的思路，不知道是否可行，还有哪些未考虑到的。因为第一期和第二期间隔的时间可能不会太久，所以最好能在一开始的设计上就要考虑周全些。
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1. Hanya lakukan caching yang sesuai
2. Jangan gunakan teknologi hanya untuk kepentingannya
Izinkan saya bercakap tentang penggunaan Redis oleh saya
1. Pertama, gunakan Redis untuk menyimpan data statik (iaitu tidak berubah atau jarang diubah. Tidak perlu memasukkannya lagi. Cache peringkat pertama menjadikan pertanyaan cache kompleks.
2. Masalahnya ialah menggunakan Redis untuk menyimpan data pembolehubah, iaitu, data yang perlu diubah suai, akan menjadi sangat menyusahkan pada masa ini, kerana pada masa ini Redis tidak dapat menggantikan sepenuhnya fungsi storan DB, iaitu, data akhir masih perlu dimasukkan ke dalam DB Untuk kegigihan, ini melibatkan isu penyegerakan antara redis dan db. Penyelesaian saya dalam projek ini adalah untuk mengubah suai Redis terlebih dahulu, kemudian mengubah suai DB secara tak segerak, dan akhirnya menyegerakkan DB ke Redis, kerana keperluan konsistensi data cache saya sangat ketat.
3. Dalam projek, data cincang akan disoal berdasarkan kunci, tetapi permintaan akan meminta sebahagian daripada data utama dalam cincang secara berasingan Untuk mendapatkan Kunci yang sama beberapa kali daripada Redis untuk setiap permintaan. cache memori JVM diperkenalkan , iaitu cache peringkat pertama yang disebut oleh soalan, bertujuan untuk mengurangkan bilangan akses kepada Redis, tetapi tujuan utama cache peringkat pertama ini adalah untuk menggabungkan berbilang permintaan untuk kunci yang sama. . Cache akhir mesti masih berdasarkan Redis, lagipun, memori JVM Sangat terhad.
1. Anda tidak seharusnya menyimpan cache dalam memori sendiri, menggunakan memcache atau redis secara langsung.
CPU mempunyai berbilang teras Secara umumnya, satu teras mempunyai satu pekerja, dan memori tidak dikongsi Jika terdapat 8 teras dan anda cache dalam aplikasi, ia bersamaan dengan 8 cache. Sudah tentu anda boleh menggunakan memori yang dikongsi, tetapi anda perlu berurusan dengan berbilang interaksi pekerja. Jadi biarkan memcache dan redis melakukannya.
2. Kelewatan rangkaian adalah sangat kecil dan boleh diabaikan untuk masa tindak balas http, biasanya di bawah 0.1ms.
3. Jangan gunakan cache berbilang peringkat Jika ia tidak mencukupi, tingkatkan memori memcache.
4. Hanya cache, iaitu, hanya tulis ke pangkalan data semasa menulis, dan kemudian padam cache memcache yang sepadan. Apabila membaca, pergi ke memcache dahulu, pergi ke pangkalan data jika ia gagal, dan kemudian tulis ke memcache.