用了redis后，接口是不是就可以多臺(tái)服務(wù)器了，用一個(gè)redis或一個(gè)redis集群，就可以？集合集合集合中不允許重復(fù)元素，這與C標(biāo)準(zhǔn)庫中的集合容器完全相同。換句話說，如果同一個(gè)元素被多次添加，那么在

用了redis后，接口是不是就可以多臺(tái)服務(wù)器了，用一個(gè)redis或一個(gè)redis集群，就可以？

集合集合集合中不允許重復(fù)元素，這與C標(biāo)準(zhǔn)庫中的集合容器完全相同。換句話說，如果同一個(gè)元素被多次添加，那么在集合中只保留該元素的一個(gè)副本。與列表類型相比，集合類型在功能上還有一個(gè)非常重要的特點(diǎn)，即可以在服務(wù)器端完成多個(gè)集合之間的并、交、差等聚合計(jì)算操作。因?yàn)檫@些操作都是在服務(wù)器上完成的，所以效率很高，節(jié)省了大量的網(wǎng)絡(luò)IO開銷。

達(dá)到物理網(wǎng)卡上限，突然幾十萬的請(qǐng)求訪問Redis的某個(gè)key如何解決？

對(duì)于手持4T redis實(shí)例組，突發(fā)請(qǐng)求的峰值為500000 ops。由于mget的廣泛使用，每秒實(shí)際請(qǐng)求數(shù)百萬個(gè)密鑰。

萬兆網(wǎng)絡(luò)，物理網(wǎng)卡不是瓶頸，CPU不是，設(shè)計(jì)不好容易成為瓶頸。

大多數(shù)用戶都是kV。用list和set分享老板的答案似乎是合理的

~]。

不要告訴我們是否使用redis。你必須告訴我們你為什么要使用redis。沒有redis的業(yè)務(wù)怎么了？世界上沒有免費(fèi)的午餐。如果不直接使用頭部緩存/NoSQL，可能會(huì)帶來越來越嚴(yán)重的問題。

單個(gè)數(shù)據(jù)庫的最大優(yōu)點(diǎn)是易于實(shí)現(xiàn)事務(wù)，并由數(shù)據(jù)庫本身保證。舉個(gè)簡單的例子，要下訂單，需要扣除庫存并插入訂單條目。如果inventory和order都是數(shù)據(jù)庫表?xiàng)l目，那么這個(gè)事務(wù)是無可挑剔的。如果庫存在redis中，訂單條目是mysql，通常需要先寫redis，成功后再寫數(shù)據(jù)庫。如果您寫數(shù)據(jù)庫失敗，需要回滾redis，如果由于網(wǎng)絡(luò)或其他原因回滾失敗，將再扣減一個(gè)存貨。不要認(rèn)為這些事情很容易解決。事務(wù)處理的復(fù)雜性遠(yuǎn)遠(yuǎn)超出您的想象。例如，當(dāng)您編寫mysql時(shí)，您在提交時(shí)就失去了連接。你無法判斷提交是成功還是失敗。你的redis是不是在倒退？

因此，當(dāng)您引入一個(gè)新層時(shí)，您必須弄清楚您必須使用cache/NoSQL的目的以及您可以接受的一致性模型。否則，你就要出丑了。