What if redis breaks down?

A few days ago, I discussed the problem of their cluster with a friend in the middle of the night . I am probably 7 Years ago, I did a cluster scrapping thing （ Fortunately, the experimental environment is groping ） Restart all nodes at once （ It was installed on a machine ）. In this case, the machine has been restarted, and all nodes have been restarted ,cluster The big feature is that more than half of them survive . In this case, persistence is turned on , His clusters can't be combined .（ Maybe some experts have other ways , I couldn't help it at that time , Reconstructed ）.

    I was thinking about a problem , If redis In case it breaks down or breaks down . We can't get by ？ It's bound to happen .redis Didn't the system be built before it was invented ？

    First of all, let's see redis What to save ？ Keep a log , get out .   Generally speaking, we will talk about two scenarios A Keep talking , also B cache . I don't need other personal views .A Scene if you say redis broken , Just one more , This information does not need to be persistent , If it's gone, it's gone , It doesn't matter .B The scene is actually a bit deadly , We usually in order to alleviate RDBMS The pressure of the , That is to let NoSQL To help , Relational databases concentrate on online transactions . So high frequency reading is put into Redis Reduce the pressure of accessing relational databases .  

  The cache here has B1 This source is a record of a relational database , Read over and over again （ But consistency is not so high ）, Then put it in Redis in , It almost doesn't matter , For example, the number of likes .B2 The scenario is to put the statistical results of the relational database into Redis in . Once encountered redis broken , Or the cache is broken down . Then there are two phenomena , One is to report errors directly and cannot provide services . There is also a way to spend your life aggregating in relational databases , The result is that the relational database is no longer available .

    So I have always advocated B2 The scenario is landing in the relational database ,redis Once something goes wrong , Check the table of relational database , Because it's a check , So the pressure is actually ok . After all, it is the settlement result of direct reading , Instead of real-time computing . There is an essential difference . and Redis Single thread , Relational databases are either multi-threaded or multi process . The configuration of the database server must be resistant .

  namely redis It doesn't affect the main process if it breaks , At most, it adds a little unpleasant pressure to relational databases . and redis Daily is to take these auxiliary pressures to bear . We can't put the cart before the horse , Give Way redis Become the core link , In this way, the whole pressure is on the single thread , Unscientific . Unless the business volume is really small , Single threading is properly supported , Should be regarded as a different matter .

    There must be someone who can't use it normally , We still need to be able to use it . To believe in Oracle、MySQL、PG also TiDB The ability of transaction database to process cache is enough , But these are not core competitiveness , Subcontract to an excellent integrator . When integrators have problems , Party A should also be able to go on . It can't be said that integrators don't do it anymore , Party A is also closed . Personal humble opinion .