├── .gitignore ├── ChatRecords ├── 190422-112220.png ├── 190423-113115.png ├── 190424-071329.png ├── 190425-121342.png ├── 190425-132122.png ├── 190425-140556.png ├── 190425-150124.png ├── 190425-150158.png ├── 190425-153811.png ├── 190425-174517.png ├── 190425-175847.png ├── 190426-112401.png ├── 190426-112416.png ├── 190426-112645.png ├── 190428-171710.png ├── 190428-171743.png ├── 190428-171801.png ├── 190430-171746.png ├── 190503-075028.png ├── 190503-174932.png ├── 190504-084546.png ├── 190506-134417.png ├── 190507-094802.png ├── 190508-182850.png ├── 190509-103750.png ├── 190509-164950.png ├── 190510-022206.png ├── 190510-182312.png ├── 190514-200357.png ├── 190518-052523.png ├── 190520-063317.png ├── 190523-114128.png ├── 190524-003649.png ├── 190602-190936.png ├── 190605-212106.png ├── 190605-212301.png ├── 190605-212643.png ├── 190606-010209.png ├── 190610-075530.png ├── 190614-155837.png ├── 190614-162110.png ├── 190615-194357.png ├── 190619-121043.png ├── 190619-123832.png ├── 190621-122736.png ├── 190624-014452.png ├── 190625-101616.png ├── 190625-103735.png ├── 190628-030207.png ├── 190628-032511.png ├── 190705-024744.png ├── 190710-094014.png ├── 190712-081343.png ├── 190717-103613.png ├── 190718-082217.png ├── 190718-085016.png ├── 190718-085224.png ├── 190718-085712.png ├── 190718-094513.png ├── 190718-103845.png ├── 190725-182421.png ├── 190725-182530.png ├── 190801-092348.png ├── 190801-094231.png ├── 190806-201206.png ├── 190806-204338.png ├── 190807-081829.png ├── 190807-125747.png ├── 190807-132650.png ├── 190809-152753.png ├── 190809-175052.png ├── 190809-180054.png ├── 190811-221701.png ├── 190812-104059.png ├── 190812-114457.png ├── 190812-172326.png ├── 190812-182531.png ├── 190816-171021.png ├── 190828-090250.png ├── 190828-090310.png ├── 191011-142929.png ├── 191016-002423.png ├── 200102-170437.png ├── 200102-170527.png ├── 200103-175635.png ├── itchat.pkl ├── main ├── main.2019-04-21.log ├── main.2019-04-22.log ├── main.2019-04-23.log ├── main.2019-04-24.log ├── main.2019-04-25.log ├── main.2019-04-26.log ├── main.2019-04-27.log ├── main.2019-04-28.log ├── main.2019-04-29.log ├── main.2019-04-30.log ├── main.2019-05-01.log ├── main.2019-05-03.log ├── main.2019-05-04.log ├── main.2019-05-05.log ├── main.2019-05-06.log ├── main.2019-05-07.log ├── main.2019-05-08.log ├── main.2019-05-09.log ├── main.2019-05-10.log ├── main.2019-05-12.log ├── main.2019-05-13.log ├── main.2019-05-14.log ├── main.2019-05-15.log ├── main.2019-05-16.log ├── main.2019-05-17.log ├── main.2019-05-18.log ├── main.2019-05-19.log ├── main.2019-05-20.log ├── main.2019-05-21.log ├── main.2019-05-22.log ├── main.2019-05-23.log ├── main.2019-05-24.log ├── main.2019-05-25.log ├── main.2019-05-26.log ├── main.2019-05-27.log ├── main.2019-05-28.log ├── main.2019-05-29.log ├── main.2019-05-30.log ├── main.2019-06-01.log ├── main.2019-06-02.log ├── main.2019-06-04.log ├── main.2019-06-05.log ├── main.2019-06-06.log ├── main.2019-06-09.log ├── main.2019-06-10.log ├── main.2019-06-11.log ├── main.2019-06-12.log ├── main.2019-06-13.log ├── main.2019-06-14.log ├── main.2019-06-15.log ├── main.2019-06-16.log ├── main.2019-06-18.log ├── main.2019-06-19.log ├── main.2019-06-20.log ├── main.2019-06-21.log ├── main.2019-06-22.log ├── main.2019-06-23.log ├── main.2019-06-24.log ├── main.2019-06-25.log ├── main.2019-06-26.log ├── main.2019-06-27.log ├── main.2019-06-28.log ├── main.2019-06-29.log ├── main.2019-06-30.log ├── main.2019-07-01.log ├── main.2019-07-02.log ├── main.2019-07-03.log ├── main.2019-07-04.log ├── main.2019-07-05.log ├── main.2019-07-07.log ├── main.2019-07-08.log ├── main.2019-07-09.log ├── main.2019-07-10.log ├── main.2019-07-11.log ├── main.2019-07-12.log ├── main.2019-07-13.log ├── main.2019-07-15.log ├── main.2019-07-16.log ├── main.2019-07-17.log ├── main.2019-07-18.log ├── main.2019-07-21.log ├── main.2019-07-22.log ├── main.2019-07-23.log ├── main.2019-07-24.log ├── main.2019-07-25.log ├── main.2019-07-26.log ├── main.2019-07-27.log ├── main.2019-07-29.log ├── main.2019-07-30.log ├── main.2019-07-31.log ├── main.2019-08-01.log ├── main.2019-08-02.log ├── main.2019-08-03.log ├── main.2019-08-05.log ├── main.2019-08-06.log ├── main.2019-08-07.log ├── main.2019-08-08.log ├── main.2019-08-09.log ├── main.2019-08-10.log ├── main.2019-08-11.log ├── main.2019-08-12.log ├── main.2019-08-13.log ├── main.2019-08-14.log ├── main.2019-08-16.log ├── main.2019-08-19.log ├── main.2019-08-20.log ├── main.2019-08-21.log ├── main.2019-08-23.log ├── main.2019-08-25.log ├── main.2019-08-27.log ├── main.2019-08-28.log ├── main.2019-08-30.log ├── main.2019-09-03.log ├── main.2019-09-07.log ├── main.2019-09-08.log ├── main.2019-09-19.log ├── main.2019-10-11.log ├── main.2019-10-14.log ├── main.2019-10-15.log ├── main.2019-10-16.log ├── main.2019-10-17.log ├── main.2019-12-31.log ├── main.2020-01-02.log ├── main.2020-01-03.log ├── nohup.out ├── redisgroup ├── redisgroup.2019-04-21.log ├── redisgroup.2019-04-22.log ├── redisgroup.2019-04-23.log ├── redisgroup.2019-04-24.log ├── redisgroup.2019-04-25.log ├── redisgroup.2019-04-26.log ├── redisgroup.2019-04-27.log ├── redisgroup.2019-04-28.log ├── redisgroup.2019-04-29.log ├── redisgroup.2019-04-30.log ├── redisgroup.2019-05-01.log ├── redisgroup.2019-05-03.log ├── redisgroup.2019-05-04.log ├── redisgroup.2019-05-05.log ├── redisgroup.2019-05-06.log ├── redisgroup.2019-05-07.log ├── redisgroup.2019-05-08.log ├── redisgroup.2019-05-09.log ├── redisgroup.2019-05-10.log ├── redisgroup.2019-05-12.log ├── redisgroup.2019-05-13.log ├── redisgroup.2019-05-14.log ├── redisgroup.2019-05-15.log ├── redisgroup.2019-05-16.log ├── redisgroup.2019-05-17.log ├── redisgroup.2019-05-18.log ├── redisgroup.2019-05-19.log ├── redisgroup.2019-05-20.log ├── redisgroup.2019-05-21.log ├── redisgroup.2019-05-22.log ├── redisgroup.2019-05-23.log ├── redisgroup.2019-05-24.log ├── redisgroup.2019-05-25.log ├── redisgroup.2019-05-26.log ├── redisgroup.2019-05-27.log ├── redisgroup.2019-05-28.log ├── redisgroup.2019-05-29.log ├── redisgroup.2019-05-30.log ├── redisgroup.2019-06-01.log ├── redisgroup.2019-06-02.log ├── redisgroup.2019-06-04.log ├── redisgroup.2019-06-05.log ├── redisgroup.2019-06-06.log ├── redisgroup.2019-06-09.log ├── redisgroup.2019-06-10.log ├── redisgroup.2019-06-11.log ├── redisgroup.2019-06-12.log ├── redisgroup.2019-06-13.log ├── redisgroup.2019-06-14.log ├── redisgroup.2019-06-15.log ├── redisgroup.2019-06-16.log ├── redisgroup.2019-06-18.log ├── redisgroup.2019-06-19.log ├── redisgroup.2019-06-20.log ├── redisgroup.2019-06-21.log ├── redisgroup.2019-06-22.log ├── redisgroup.2019-06-23.log ├── redisgroup.2019-06-24.log ├── redisgroup.2019-06-25.log ├── redisgroup.2019-06-26.log ├── redisgroup.2019-06-27.log ├── redisgroup.2019-06-28.log ├── redisgroup.2019-06-29.log ├── redisgroup.2019-06-30.log ├── redisgroup.2019-07-01.log ├── redisgroup.2019-07-02.log ├── redisgroup.2019-07-03.log ├── redisgroup.2019-07-04.log ├── redisgroup.2019-07-05.log ├── redisgroup.2019-07-07.log ├── redisgroup.2019-07-08.log ├── redisgroup.2019-07-09.log ├── redisgroup.2019-07-10.log ├── redisgroup.2019-07-11.log ├── redisgroup.2019-07-12.log ├── redisgroup.2019-07-13.log ├── redisgroup.2019-07-15.log ├── redisgroup.2019-07-16.log ├── redisgroup.2019-07-17.log ├── redisgroup.2019-07-18.log ├── redisgroup.2019-07-21.log ├── redisgroup.2019-07-22.log ├── redisgroup.2019-07-24.log ├── redisgroup.2019-07-25.log ├── redisgroup.2019-07-26.log ├── redisgroup.2019-07-27.log ├── redisgroup.2019-07-29.log ├── redisgroup.2019-07-30.log ├── redisgroup.2019-07-31.log ├── redisgroup.2019-08-01.log ├── redisgroup.2019-08-02.log ├── redisgroup.2019-08-03.log ├── redisgroup.2019-08-05.log ├── redisgroup.2019-08-06.log ├── redisgroup.2019-08-07.log ├── redisgroup.2019-08-08.log ├── redisgroup.2019-08-09.log ├── redisgroup.2019-08-10.log ├── redisgroup.2019-08-11.log ├── redisgroup.2019-08-12.log ├── redisgroup.2019-08-13.log ├── redisgroup.2019-08-14.log ├── redisgroup.2019-08-16.log ├── redisgroup.2019-08-19.log ├── redisgroup.2019-08-20.log ├── redisgroup.2019-08-21.log ├── redisgroup.2019-08-23.log ├── redisgroup.2019-08-25.log ├── redisgroup.2019-08-27.log ├── redisgroup.2019-08-28.log ├── redisgroup.2019-09-03.log ├── redisgroup.2019-09-07.log ├── redisgroup.2019-09-08.log ├── redisgroup.2019-09-19.log ├── redisgroup.2019-10-11.log ├── redisgroup.2019-10-14.log ├── redisgroup.2019-10-15.log ├── redisgroup.2019-10-16.log ├── redisgroup.2020-01-02.log ├── redisgroup.2020-01-03.log └── syncgroupchat.py ├── CodeDesignRule ├── README.md ├── app1.png ├── applicaiton.md ├── client.md ├── dataexception.md ├── expire.md ├── keydesign.md ├── lat1.png ├── lat2.png ├── lat3.png ├── lat4.png ├── latency.md ├── mem1.png ├── mem2.png ├── mem3.png ├── memory.md └── redis命令参考.pdf ├── DataStructure ├── README.md ├── hash │ ├── README.md │ ├── hdel.md │ ├── hexists.md │ ├── hget.md │ ├── hgetall.md │ ├── hincrby.md │ ├── hkeys.md │ ├── hlen.md │ ├── hset.md │ └── hvals.md ├── hyperloglog │ ├── README.md │ ├── pfadd.md │ ├── pfcount.md │ └── pfmerge.md ├── key │ ├── README.md │ ├── del.md │ ├── exist.md │ ├── expire.md │ ├── list.md │ ├── randomkey.md │ ├── rename.md │ ├── scan-compare.png │ ├── scan-intro.png │ ├── scan-other.png │ ├── scan.png │ └── type.md ├── list │ ├── README.md │ ├── addlist.md │ ├── blocklist.md │ ├── del.md │ ├── lindex.md │ ├── llen.md │ ├── lrange.md │ ├── lset.md │ └── ltrim.md ├── set │ ├── README.md │ ├── sadd.md │ ├── scard.md │ ├── sdiff.md │ ├── sinter.md │ ├── sismember.md │ ├── smembers.md │ ├── smove.md │ ├── spop.md │ ├── srandmember.md │ ├── srem.md │ └── sunion.md ├── string │ ├── README.md │ ├── append.md │ ├── bit1.png │ ├── bit2.png │ ├── bitop.md │ ├── chinese.md │ ├── chinese.png │ ├── get.md │ ├── getrange.md │ ├── incr1.png │ ├── incrdecr.md │ ├── incrfloat.png │ ├── set.md │ ├── setrange.md │ ├── setrange.png │ ├── setrange0.png │ ├── strlen.md │ └── substr.md ├── timecomplex.gif └── zset │ ├── README.md │ ├── ZUNIONSTORE.md │ ├── zadd.md │ ├── zcard.md │ ├── zcount.md │ ├── zincrby.md │ ├── zrange.md │ ├── zrangebyscore.md │ ├── zrank.md │ ├── zrem.md │ └── zscore.md ├── Dockerfile ├── HAClusterArchPractice ├── README.md └── ms │ ├── README.md │ ├── deploy-1.png │ ├── deploy.md │ ├── deployarch.md │ ├── deployconfig.md │ ├── deploydict.md │ ├── deploynet.md │ ├── deploypersist.md │ ├── deploystep.md │ ├── deployuser.md │ ├── event-noti.md │ ├── failoverprinciple.md │ ├── findprinciple.md │ ├── haprinciple.md │ ├── hatest-brainsplit.md │ ├── hatest-doublesdown.md │ ├── hatest-doublestdown.md │ ├── hatest-env.md │ ├── hatest-manufailover.md │ ├── hatest-masterdown.md │ ├── hatest-masterhang.md │ ├── hatest-mastermachdown.md │ ├── hatest-quorum.md │ ├── hatest-sentinelconf.md │ ├── hatest-sentinelevent.md │ ├── hatest-singlesdown.md │ ├── hatest-singlestdown.md │ ├── hatest-slavemachdown.md │ ├── hatest.md │ ├── hatest1.png │ ├── hatest10.png │ ├── hatest11.png │ ├── hatest12.png │ ├── hatest13.png │ ├── hatest14.png │ ├── hatest15.png │ ├── hatest16.png │ ├── hatest17.png │ ├── hatest18.png │ ├── hatest19.png │ ├── hatest2.png │ ├── hatest20.png │ ├── hatest21.png │ ├── hatest22.png │ ├── hatest23.png │ ├── hatest24.png │ ├── hatest25.png │ ├── hatest26.png │ ├── hatest27.png │ ├── hatest28.png │ ├── hatest29.png │ ├── hatest3.png │ ├── hatest4.png │ ├── hatest5.png │ ├── hatest6.png │ ├── hatest7.png │ ├── hatest8.png │ ├── hatest9.png │ ├── operation-boot.md │ ├── operation-failover.md │ ├── operation-manu-start.md │ ├── operation-masterconfig.md │ ├── operation-masteripport.md │ ├── operation-modifyconf.md │ ├── operation-msconsistence.md │ ├── operation-resetst.md │ ├── operation-startstop.md │ ├── operation-startstopsentinel.md │ ├── operation-ststate.md │ ├── operation-subevent.md │ ├── operation.md │ ├── other1.png │ ├── other2.png │ ├── other3.png │ ├── other4.png │ ├── other5.png │ ├── others.md │ ├── persistence-change.md │ ├── readonly.md │ ├── sentinel-maxconn.md │ └── virtualip.md ├── HAClusterBrief ├── README.md ├── comparison.md ├── concept.md ├── scenario.md └── sharding.md ├── IndependentFunc ├── README.md ├── pipeline.md ├── pubsub.md ├── sort.md ├── sort1.png ├── sort2.png └── transection.md ├── Intro └── README.md ├── LICENSE ├── Migration ├── README.md └── move.md ├── Monitor └── monitor.md ├── Operation ├── README.md ├── auth.md ├── benchmark.md ├── bulk.md ├── config.md ├── flush.md ├── lua.md ├── password.md ├── persistence-backup │ ├── README.md │ ├── aof.md │ ├── backup.md │ ├── rdb.md │ ├── recovery.md │ └── recovery.png ├── redis-cli.md ├── rename-command.md ├── select.md ├── start.md └── stop.md ├── Problem ├── README.md ├── general │ ├── README.md │ ├── checkfix-aof.md │ ├── client.md │ ├── info.md │ ├── latency-detect.md │ ├── log.md │ ├── monitor.md │ ├── redis-stat.md │ ├── service-detect.md │ └── slowlog.md ├── latency │ ├── README.md │ ├── commands.md │ ├── cpu.md │ ├── network.md │ ├── overall-check.md │ ├── persistence-check.md │ └── total-commands.md └── memory │ ├── README.md │ ├── debug-key.md │ ├── faina.md │ ├── info.md │ ├── rdb-tool.md │ ├── rss.md │ ├── sample.md │ ├── scan-bigkey.md │ ├── swap.md │ └── system-memory.md ├── ProdEnvDeploy ├── README.md ├── conf.md ├── memory.md ├── multi-instance.md ├── persistence.md ├── rps.md ├── servers.md └── tips.md ├── README.md ├── SUMMARY.md ├── Security ├── README.md └── shell.md ├── Testing ├── README.md ├── aof-reload.md ├── down.md ├── hang.md ├── oom.md ├── populate.md └── rdb-reload.md ├── config.json ├── cover ├── background.jpg └── logo.png ├── images ├── alipay-qrcode.jpg ├── lookingfor-100.jpg ├── lookingfor.jpg ├── redis-stat.png ├── weixin-group.png ├── weixin-qrcode.jpg └── xingqiu.jpg ├── push.bat └── redisgroup /.gitignore: -------------------------------------------------------------------------------- 1 | *.bat 2 | .idea/ 3 | -------------------------------------------------------------------------------- /ChatRecords/190422-112220.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190422-112220.png -------------------------------------------------------------------------------- /ChatRecords/190423-113115.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190423-113115.png -------------------------------------------------------------------------------- /ChatRecords/190424-071329.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190424-071329.png -------------------------------------------------------------------------------- /ChatRecords/190425-121342.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-121342.png -------------------------------------------------------------------------------- /ChatRecords/190425-132122.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-132122.png -------------------------------------------------------------------------------- /ChatRecords/190425-140556.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-140556.png -------------------------------------------------------------------------------- /ChatRecords/190425-150124.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-150124.png -------------------------------------------------------------------------------- /ChatRecords/190425-150158.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-150158.png -------------------------------------------------------------------------------- /ChatRecords/190425-153811.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-153811.png -------------------------------------------------------------------------------- /ChatRecords/190425-174517.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-174517.png -------------------------------------------------------------------------------- /ChatRecords/190425-175847.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190425-175847.png -------------------------------------------------------------------------------- /ChatRecords/190426-112401.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190426-112401.png -------------------------------------------------------------------------------- /ChatRecords/190426-112416.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190426-112416.png -------------------------------------------------------------------------------- /ChatRecords/190426-112645.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190426-112645.png -------------------------------------------------------------------------------- /ChatRecords/190428-171710.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190428-171710.png -------------------------------------------------------------------------------- /ChatRecords/190428-171743.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190428-171743.png -------------------------------------------------------------------------------- /ChatRecords/190428-171801.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190428-171801.png -------------------------------------------------------------------------------- /ChatRecords/190430-171746.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190430-171746.png -------------------------------------------------------------------------------- /ChatRecords/190503-075028.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190503-075028.png -------------------------------------------------------------------------------- /ChatRecords/190503-174932.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190503-174932.png -------------------------------------------------------------------------------- /ChatRecords/190504-084546.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190504-084546.png -------------------------------------------------------------------------------- /ChatRecords/190506-134417.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190506-134417.png -------------------------------------------------------------------------------- /ChatRecords/190507-094802.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190507-094802.png -------------------------------------------------------------------------------- /ChatRecords/190508-182850.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190508-182850.png -------------------------------------------------------------------------------- /ChatRecords/190509-103750.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190509-103750.png -------------------------------------------------------------------------------- /ChatRecords/190509-164950.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190509-164950.png -------------------------------------------------------------------------------- /ChatRecords/190510-022206.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190510-022206.png -------------------------------------------------------------------------------- /ChatRecords/190510-182312.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190510-182312.png -------------------------------------------------------------------------------- /ChatRecords/190514-200357.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190514-200357.png -------------------------------------------------------------------------------- /ChatRecords/190518-052523.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190518-052523.png -------------------------------------------------------------------------------- /ChatRecords/190520-063317.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190520-063317.png -------------------------------------------------------------------------------- /ChatRecords/190523-114128.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190523-114128.png -------------------------------------------------------------------------------- /ChatRecords/190524-003649.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190524-003649.png -------------------------------------------------------------------------------- /ChatRecords/190602-190936.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190602-190936.png -------------------------------------------------------------------------------- /ChatRecords/190605-212106.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190605-212106.png -------------------------------------------------------------------------------- /ChatRecords/190605-212301.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190605-212301.png -------------------------------------------------------------------------------- /ChatRecords/190605-212643.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190605-212643.png -------------------------------------------------------------------------------- /ChatRecords/190606-010209.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190606-010209.png -------------------------------------------------------------------------------- /ChatRecords/190610-075530.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190610-075530.png -------------------------------------------------------------------------------- /ChatRecords/190614-155837.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190614-155837.png -------------------------------------------------------------------------------- /ChatRecords/190614-162110.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190614-162110.png -------------------------------------------------------------------------------- /ChatRecords/190615-194357.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190615-194357.png -------------------------------------------------------------------------------- /ChatRecords/190619-121043.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190619-121043.png -------------------------------------------------------------------------------- /ChatRecords/190619-123832.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190619-123832.png -------------------------------------------------------------------------------- /ChatRecords/190621-122736.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190621-122736.png -------------------------------------------------------------------------------- /ChatRecords/190624-014452.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190624-014452.png -------------------------------------------------------------------------------- /ChatRecords/190625-101616.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190625-101616.png -------------------------------------------------------------------------------- /ChatRecords/190625-103735.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190625-103735.png -------------------------------------------------------------------------------- /ChatRecords/190628-030207.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190628-030207.png -------------------------------------------------------------------------------- /ChatRecords/190628-032511.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190628-032511.png -------------------------------------------------------------------------------- /ChatRecords/190705-024744.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190705-024744.png -------------------------------------------------------------------------------- /ChatRecords/190710-094014.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190710-094014.png -------------------------------------------------------------------------------- /ChatRecords/190712-081343.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190712-081343.png -------------------------------------------------------------------------------- /ChatRecords/190717-103613.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190717-103613.png -------------------------------------------------------------------------------- /ChatRecords/190718-082217.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-082217.png -------------------------------------------------------------------------------- /ChatRecords/190718-085016.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-085016.png -------------------------------------------------------------------------------- /ChatRecords/190718-085224.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-085224.png -------------------------------------------------------------------------------- /ChatRecords/190718-085712.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-085712.png -------------------------------------------------------------------------------- /ChatRecords/190718-094513.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-094513.png -------------------------------------------------------------------------------- /ChatRecords/190718-103845.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190718-103845.png -------------------------------------------------------------------------------- /ChatRecords/190725-182421.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190725-182421.png -------------------------------------------------------------------------------- /ChatRecords/190725-182530.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190725-182530.png -------------------------------------------------------------------------------- /ChatRecords/190801-092348.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190801-092348.png -------------------------------------------------------------------------------- /ChatRecords/190801-094231.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190801-094231.png -------------------------------------------------------------------------------- /ChatRecords/190806-201206.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190806-201206.png -------------------------------------------------------------------------------- /ChatRecords/190806-204338.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190806-204338.png -------------------------------------------------------------------------------- /ChatRecords/190807-081829.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190807-081829.png -------------------------------------------------------------------------------- /ChatRecords/190807-125747.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190807-125747.png -------------------------------------------------------------------------------- /ChatRecords/190807-132650.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190807-132650.png -------------------------------------------------------------------------------- /ChatRecords/190809-152753.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190809-152753.png -------------------------------------------------------------------------------- /ChatRecords/190809-175052.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190809-175052.png -------------------------------------------------------------------------------- /ChatRecords/190809-180054.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190809-180054.png -------------------------------------------------------------------------------- /ChatRecords/190811-221701.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190811-221701.png -------------------------------------------------------------------------------- /ChatRecords/190812-104059.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190812-104059.png -------------------------------------------------------------------------------- /ChatRecords/190812-114457.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190812-114457.png -------------------------------------------------------------------------------- /ChatRecords/190812-172326.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190812-172326.png -------------------------------------------------------------------------------- /ChatRecords/190812-182531.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190812-182531.png -------------------------------------------------------------------------------- /ChatRecords/190816-171021.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190816-171021.png -------------------------------------------------------------------------------- /ChatRecords/190828-090250.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190828-090250.png -------------------------------------------------------------------------------- /ChatRecords/190828-090310.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/190828-090310.png -------------------------------------------------------------------------------- /ChatRecords/191011-142929.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/191011-142929.png -------------------------------------------------------------------------------- /ChatRecords/191016-002423.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/191016-002423.png -------------------------------------------------------------------------------- /ChatRecords/200102-170437.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/200102-170437.png -------------------------------------------------------------------------------- /ChatRecords/200102-170527.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/200102-170527.png -------------------------------------------------------------------------------- /ChatRecords/200103-175635.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/200103-175635.png -------------------------------------------------------------------------------- /ChatRecords/main: -------------------------------------------------------------------------------- 1 | 2020-01-04 12:06:18,702 Records log has been rotating... 2 | 2020-01-04 12:06:42,192 正在监测的群聊：2 个 3 | 2020-01-04 12:06:42,193 Redis技术交流群2 Redis技术交流群 4 | 2020-01-04 12:12:07,680 Records log has been rotating... 5 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-21.log: -------------------------------------------------------------------------------- 1 | 2019-04-21 10:06:09,579 正在监测的群聊：2 个 2 | 2019-04-21 10:06:09,637 Redis技术交流群 Redis技术交流群2 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-22.log: -------------------------------------------------------------------------------- 1 | 2019-04-22 07:12:40,043 Records log has been rotating... 2 | 2019-04-22 07:12:40,036 Records log has been rotating... 3 | 2019-04-22 11:54:24,052 正在监测的群聊：2 个 4 | 2019-04-22 11:54:24,052 Redis技术交流群 Redis技术交流群2 5 | 2019-04-22 11:49:58,514 正在监测的群聊：2 个 6 | 2019-04-22 11:49:58,529 Redis技术交流群 Redis技术交流群2 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-23.log: -------------------------------------------------------------------------------- 1 | 2019-04-23 09:25:31,094 Records log has been rotating... 2 | 2019-04-23 09:25:31,078 Records log has been rotating... 3 | 2019-04-23 15:25:33,406 正在监测的群聊：1 个 4 | 2019-04-23 15:25:33,423 Redis技术交流群 5 | 2019-04-23 15:28:15,247 正在监测的群聊：2 个 6 | 2019-04-23 15:28:15,491 Redis技术交流群 Redis技术交流群2 7 | 2019-04-23 15:29:59,960 正在监测的群聊：2 个 8 | 2019-04-23 15:29:59,972 Redis技术交流群 Redis技术交流群2 9 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-24.log: -------------------------------------------------------------------------------- 1 | 2019-04-24 07:13:48,865 Records log has been rotating... 2 | 2019-04-24 07:13:48,865 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-25.log: -------------------------------------------------------------------------------- 1 | 2019-04-25 09:52:11,142 Records log has been rotating... 2 | 2019-04-25 09:52:11,142 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-26.log: -------------------------------------------------------------------------------- 1 | 2019-04-26 10:28:46,103 Records log has been rotating... 2 | 2019-04-26 10:28:46,102 正在监测的群聊：2 个 3 | 2019-04-26 10:28:55,708 Redis技术交流群 Redis技术交流群2 4 | 2019-04-26 10:30:46,738 正在监测的群聊：2 个 5 | 2019-04-26 10:30:46,835 Redis技术交流群 Redis技术交流群2 6 | 2019-04-26 10:32:53,737 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-27.log: -------------------------------------------------------------------------------- 1 | 2019-04-27 07:45:50,255 Records log has been rotating... 2 | 2019-04-27 07:45:50,250 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-28.log: -------------------------------------------------------------------------------- 1 | 2019-04-28 17:17:10,954 Records log has been rotating... 2 | 2019-04-28 17:17:10,940 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-29.log: -------------------------------------------------------------------------------- 1 | 2019-04-29 06:55:04,331 Records log has been rotating... 2 | 2019-04-29 06:55:04,330 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-04-30.log: -------------------------------------------------------------------------------- 1 | 2019-04-30 11:16:14,303 Records log has been rotating... 2 | 2019-04-30 11:16:14,135 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-01.log: -------------------------------------------------------------------------------- 1 | 2019-05-01 22:59:21,948 Records log has been rotating... 2 | 2019-05-01 22:59:21,941 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-03.log: -------------------------------------------------------------------------------- 1 | 2019-05-03 07:50:02,429 Records log has been rotating... 2 | 2019-05-03 07:50:02,429 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-04.log: -------------------------------------------------------------------------------- 1 | 2019-05-04 08:45:39,537 Records log has been rotating... 2 | 2019-05-04 08:45:39,537 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-05.log: -------------------------------------------------------------------------------- 1 | 2019-05-05 09:35:29,484 Records log has been rotating... 2 | 2019-05-05 09:35:29,474 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-06.log: -------------------------------------------------------------------------------- 1 | 2019-05-06 01:03:30,205 Records log has been rotating... 2 | 2019-05-06 01:03:30,204 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-07.log: -------------------------------------------------------------------------------- 1 | 2019-05-07 09:48:03,354 Records log has been rotating... 2 | 2019-05-07 09:48:03,354 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-08.log: -------------------------------------------------------------------------------- 1 | 2019-05-08 06:29:38,436 Records log has been rotating... 2 | 2019-05-08 06:29:38,425 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-09.log: -------------------------------------------------------------------------------- 1 | 2019-05-09 04:05:03,924 Records log has been rotating... 2 | 2019-05-09 04:05:03,923 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-10.log: -------------------------------------------------------------------------------- 1 | 2019-05-10 02:11:14,245 Records log has been rotating... 2 | 2019-05-10 02:11:14,244 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-12.log: -------------------------------------------------------------------------------- 1 | 2019-05-12 10:28:35,254 Records log has been rotating... 2 | 2019-05-12 10:28:35,204 正在监测的群聊：2 个 3 | 2019-05-12 10:28:57,863 Redis技术交流群 Redis技术交流群2 4 | 2019-05-12 10:29:47,948 正在监测的群聊：2 个 5 | 2019-05-12 10:29:48,026 Redis技术交流群 Redis技术交流群2 6 | 2019-05-12 10:37:38,754 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-13.log: -------------------------------------------------------------------------------- 1 | 2019-05-13 08:03:11,224 Records log has been rotating... 2 | 2019-05-13 08:03:11,213 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-14.log: -------------------------------------------------------------------------------- 1 | 2019-05-14 10:10:25,787 Records log has been rotating... 2 | 2019-05-14 10:10:25,779 正在监测的群聊：2 个 3 | 2019-05-14 10:10:35,557 Redis技术交流群 Redis技术交流群2 4 | 2019-05-14 10:11:03,890 正在监测的群聊：2 个 5 | 2019-05-14 10:11:03,903 Redis技术交流群 Redis技术交流群2 6 | 2019-05-14 12:41:06,666 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-15.log: -------------------------------------------------------------------------------- 1 | 2019-05-15 12:37:09,244 Records log has been rotating... 2 | 2019-05-15 12:37:09,244 Records log has been rotating... 3 | 2019-05-15 13:20:54,190 正在监测的群聊：2 个 4 | 2019-05-15 13:20:54,190 Redis技术交流群 Redis技术交流群2 5 | 2019-05-15 13:22:19,191 正在监测的群聊：2 个 6 | 2019-05-15 13:22:19,192 Redis技术交流群 Redis技术交流群2 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-16.log: -------------------------------------------------------------------------------- 1 | 2019-05-16 03:03:23,357 Records log has been rotating... 2 | 2019-05-16 03:03:23,357 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-17.log: -------------------------------------------------------------------------------- 1 | 2019-05-17 06:58:21,389 Records log has been rotating... 2 | 2019-05-17 06:58:21,389 正在监测的群聊：2 个 3 | 2019-05-17 06:58:22,509 Redis技术交流群 Redis技术交流群2 4 | 2019-05-17 06:59:14,555 正在监测的群聊：2 个 5 | 2019-05-17 06:59:14,555 Redis技术交流群 Redis技术交流群2 6 | 2019-05-17 06:59:44,590 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-18.log: -------------------------------------------------------------------------------- 1 | 2019-05-18 01:06:11,771 Records log has been rotating... 2 | 2019-05-18 01:06:11,771 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-19.log: -------------------------------------------------------------------------------- 1 | 2019-05-19 00:30:55,729 Records log has been rotating... 2 | 2019-05-19 00:30:55,729 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-20.log: -------------------------------------------------------------------------------- 1 | 2019-05-20 06:05:13,933 Records log has been rotating... 2 | 2019-05-20 06:05:13,933 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-21.log: -------------------------------------------------------------------------------- 1 | 2019-05-21 00:42:18,477 Records log has been rotating... 2 | 2019-05-21 00:42:18,477 Records log has been rotating... 3 | 2019-05-21 08:36:32,053 正在监测的群聊：2 个 4 | 2019-05-21 08:36:32,053 Redis技术交流群2 Redis技术交流群 5 | 2019-05-21 08:36:50,928 正在监测的群聊：2 个 6 | 2019-05-21 08:36:50,928 Redis技术交流群2 Redis技术交流群 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-22.log: -------------------------------------------------------------------------------- 1 | 2019-05-22 10:01:22,849 Records log has been rotating... 2 | 2019-05-22 10:01:22,849 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-23.log: -------------------------------------------------------------------------------- 1 | 2019-05-23 11:40:18,334 Records log has been rotating... 2 | 2019-05-23 11:40:18,334 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-24.log: -------------------------------------------------------------------------------- 1 | 2019-05-24 00:36:29,742 Records log has been rotating... 2 | 2019-05-24 00:36:29,742 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-25.log: -------------------------------------------------------------------------------- 1 | 2019-05-25 06:29:28,269 Records log has been rotating... 2 | 2019-05-25 06:29:28,269 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-26.log: -------------------------------------------------------------------------------- 1 | 2019-05-26 07:34:15,467 Records log has been rotating... 2 | 2019-05-26 07:34:15,467 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-27.log: -------------------------------------------------------------------------------- 1 | 2019-05-27 17:47:27,320 Records log has been rotating... 2 | 2019-05-27 17:47:27,319 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-28.log: -------------------------------------------------------------------------------- 1 | 2019-05-28 05:58:50,170 Records log has been rotating... 2 | 2019-05-28 05:58:50,170 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-29.log: -------------------------------------------------------------------------------- 1 | 2019-05-29 07:16:38,244 Records log has been rotating... 2 | 2019-05-29 07:16:38,243 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-05-30.log: -------------------------------------------------------------------------------- 1 | 2019-05-30 00:03:12,972 Records log has been rotating... 2 | 2019-05-30 00:03:12,972 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-01.log: -------------------------------------------------------------------------------- 1 | 2019-05-31 03:37:34,872 Records log has been rotating... 2 | 2019-05-31 03:37:34,871 Records log has been rotating... 3 | <<<<<<< HEAD 4 | ======= 5 | 2019-06-01 16:40:16,811 正在监测的群聊：2 个 6 | 2019-06-01 16:40:16,811 Redis技术交流群2 Redis技术交流群 7 | 2019-06-01 16:40:34,915 正在监测的群聊：2 个 8 | 2019-06-01 16:40:34,915 Redis技术交流群2 Redis技术交流群 9 | >>>>>>> 0598491f5cdc2b5cdf62d446e13d758abefac2be 10 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-02.log: -------------------------------------------------------------------------------- 1 | 2019-06-02 03:18:11,665 Records log has been rotating... 2 | 2019-06-02 03:18:11,664 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-04.log: -------------------------------------------------------------------------------- 1 | 2019-06-04 04:25:41,284 Records log has been rotating... 2 | 2019-06-04 04:25:41,283 Records log has been rotating... 3 | 2019-06-04 15:38:22,054 正在监测的群聊：2 个 4 | 2019-06-04 15:38:22,054 Redis技术交流群2 Redis技术交流群 5 | 2019-06-04 15:38:25,036 正在监测的群聊：2 个 6 | 2019-06-04 15:38:25,036 Redis技术交流群2 Redis技术交流群 7 | 2019-06-04 15:38:33,002 正在监测的群聊：2 个 8 | 2019-06-04 15:38:33,003 Redis技术交流群2 Redis技术交流群 9 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-05.log: -------------------------------------------------------------------------------- 1 | 2019-06-05 07:22:22,153 Records log has been rotating... 2 | 2019-06-05 07:22:22,153 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-06.log: -------------------------------------------------------------------------------- 1 | 2019-06-06 01:03:07,310 Records log has been rotating... 2 | 2019-06-06 01:03:07,310 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-09.log: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/main.2019-06-09.log -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-10.log: -------------------------------------------------------------------------------- 1 | 2019-06-10 08:03:31,700 Records log has been rotating... 2 | 2019-06-10 08:03:31,699 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-11.log: -------------------------------------------------------------------------------- 1 | 2019-06-11 09:05:31,211 Records log has been rotating... 2 | 2019-06-11 09:05:31,211 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-12.log: -------------------------------------------------------------------------------- 1 | 2019-06-12 07:55:46,037 Records log has been rotating... 2 | 2019-06-12 07:55:46,037 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-13.log: -------------------------------------------------------------------------------- 1 | 2019-06-13 18:19:19,878 Records log has been rotating... 2 | 2019-06-13 18:19:19,878 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-14.log: -------------------------------------------------------------------------------- 1 | 2019-06-14 15:38:31,858 Records log has been rotating... 2 | 2019-06-14 15:38:31,858 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-15.log: -------------------------------------------------------------------------------- 1 | 2019-06-15 12:34:09,951 Records log has been rotating... 2 | 2019-06-15 12:34:09,951 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-16.log: -------------------------------------------------------------------------------- 1 | 2019-06-16 08:21:46,144 Records log has been rotating... 2 | 2019-06-16 08:21:46,144 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-18.log: -------------------------------------------------------------------------------- 1 | 2019-06-17 08:47:25,280 Records log has been rotating... 2 | 2019-06-17 08:47:25,280 Records log has been rotating... 3 | 2019-06-18 01:27:38,856 正在监测的群聊：2 个 4 | 2019-06-18 01:27:38,856 Redis技术交流群 Redis技术交流群2 5 | 2019-06-18 01:28:02,464 正在监测的群聊：2 个 6 | 2019-06-18 01:28:02,464 Redis技术交流群 Redis技术交流群2 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-19.log: -------------------------------------------------------------------------------- 1 | 2019-06-19 00:22:51,926 Records log has been rotating... 2 | 2019-06-19 00:22:51,925 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-20.log: -------------------------------------------------------------------------------- 1 | 2019-06-20 00:49:08,096 Records log has been rotating... 2 | 2019-06-20 00:49:08,096 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-21.log: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/main.2019-06-21.log -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-22.log: -------------------------------------------------------------------------------- 1 | 2019-06-22 03:05:56,316 Records log has been rotating... 2 | 2019-06-22 03:05:56,316 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-23.log: -------------------------------------------------------------------------------- 1 | 2019-06-23 15:15:40,562 Records log has been rotating... 2 | 2019-06-23 15:15:40,554 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-24.log: -------------------------------------------------------------------------------- 1 | 2019-06-24 00:38:16,798 Records log has been rotating... 2 | 2019-06-24 00:38:16,798 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-25.log: -------------------------------------------------------------------------------- 1 | 2019-06-25 09:22:09,153 Records log has been rotating... 2 | 2019-06-25 09:22:09,153 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-26.log: -------------------------------------------------------------------------------- 1 | 2019-06-26 07:14:50,376 Records log has been rotating... 2 | 2019-06-26 07:14:50,376 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-27.log: -------------------------------------------------------------------------------- 1 | 2019-06-27 09:51:38,173 Records log has been rotating... 2 | 2019-06-27 09:51:38,173 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-28.log: -------------------------------------------------------------------------------- 1 | 2019-06-28 03:03:27,415 Records log has been rotating... 2 | 2019-06-28 03:03:27,415 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-29.log: -------------------------------------------------------------------------------- 1 | 2019-06-29 04:01:25,450 Records log has been rotating... 2 | 2019-06-29 04:01:25,450 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-06-30.log: -------------------------------------------------------------------------------- 1 | 2019-06-30 10:45:51,189 Records log has been rotating... 2 | 2019-06-30 10:45:51,189 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-01.log: -------------------------------------------------------------------------------- 1 | 2019-07-01 05:59:53,429 Records log has been rotating... 2 | 2019-07-01 05:59:53,429 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-02.log: -------------------------------------------------------------------------------- 1 | 2019-07-02 03:07:58,524 Records log has been rotating... 2 | 2019-07-02 03:07:58,524 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-03.log: -------------------------------------------------------------------------------- 1 | 2019-07-03 01:36:11,474 Records log has been rotating... 2 | 2019-07-03 01:36:11,474 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-04.log: -------------------------------------------------------------------------------- 1 | 2019-07-04 02:35:08,059 Records log has been rotating... 2 | 2019-07-04 02:35:08,059 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-05.log: -------------------------------------------------------------------------------- 1 | 2019-07-05 02:31:41,043 Records log has been rotating... 2 | 2019-07-05 02:31:41,043 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-07.log: -------------------------------------------------------------------------------- 1 | 2019-07-07 14:50:33,707 Records log has been rotating... 2 | 2019-07-07 14:50:33,707 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-08.log: -------------------------------------------------------------------------------- 1 | 2019-07-08 10:23:18,592 Records log has been rotating... 2 | 2019-07-08 10:23:18,592 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-09.log: -------------------------------------------------------------------------------- 1 | 2019-07-09 01:03:21,852 Records log has been rotating... 2 | 2019-07-09 01:03:21,852 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-10.log: -------------------------------------------------------------------------------- 1 | 2019-07-10 09:43:01,226 Records log has been rotating... 2 | 2019-07-10 09:43:01,226 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-11.log: -------------------------------------------------------------------------------- 1 | 2019-07-11 01:18:03,145 Records log has been rotating... 2 | 2019-07-11 01:18:03,145 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-12.log: -------------------------------------------------------------------------------- 1 | 2019-07-12 06:42:46,238 Records log has been rotating... 2 | 2019-07-12 06:42:46,237 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-13.log: -------------------------------------------------------------------------------- 1 | 2019-07-13 11:08:03,613 Records log has been rotating... 2 | 2019-07-13 11:08:03,613 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-15.log: -------------------------------------------------------------------------------- 1 | 2019-07-15 01:43:47,202 Records log has been rotating... 2 | 2019-07-15 01:43:47,201 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-16.log: -------------------------------------------------------------------------------- 1 | 2019-07-16 00:44:38,733 Records log has been rotating... 2 | 2019-07-16 00:44:38,732 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-17.log: -------------------------------------------------------------------------------- 1 | 2019-07-17 08:45:27,243 Records log has been rotating... 2 | 2019-07-17 08:45:27,243 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-18.log: -------------------------------------------------------------------------------- 1 | 2019-07-18 00:33:27,999 Records log has been rotating... 2 | 2019-07-18 00:33:27,999 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-21.log: -------------------------------------------------------------------------------- 1 | 2019-07-21 08:07:15,428 Records log has been rotating... 2 | 2019-07-21 08:07:15,427 正在监测的群聊：2 个 3 | 2019-07-21 08:07:16,933 Redis技术交流群 Redis技术交流群2 4 | 2019-07-21 08:08:45,098 正在监测的群聊：2 个 5 | 2019-07-21 08:08:45,099 Redis技术交流群 Redis技术交流群2 6 | 2019-07-21 08:12:24,541 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-22.log: -------------------------------------------------------------------------------- 1 | 2019-07-22 16:40:04,459 Records log has been rotating... 2 | 2019-07-22 16:40:04,458 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-23.log: -------------------------------------------------------------------------------- 1 | 2019-07-23 09:30:25,482 Records log has been rotating... 2 | 2019-07-23 09:30:25,482 正在监测的群聊：1 个 3 | 2019-07-23 09:30:26,906 Redis技术交流群2 4 | 2019-07-23 09:31:03,163 正在监测的群聊：1 个 5 | 2019-07-23 09:31:03,164 Redis技术交流群2 6 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-24.log: -------------------------------------------------------------------------------- 1 | <<<<<<< HEAD 2 | 2019-07-24 09:53:32,925 Records log has been rotating... 3 | 2019-07-24 09:53:32,924 正在监测的群聊：2 个 4 | 2019-07-24 09:53:33,985 Redis技术交流群 Redis技术交流群2 5 | 2019-07-24 09:54:12,539 Records log has been rotating... 6 | ======= 7 | 2019-07-19 00:05:10,029 Records log has been rotating... 8 | 2019-07-19 00:05:10,029 Records log has been rotating... 9 | >>>>>>> 0598491f5cdc2b5cdf62d446e13d758abefac2be 10 | 2019-07-24 10:00:04,184 正在监测的群聊：2 个 11 | 2019-07-24 10:00:04,185 Redis技术交流群 Redis技术交流群2 12 | 2019-07-24 10:00:19,417 正在监测的群聊：2 个 13 | 2019-07-24 10:00:19,417 Redis技术交流群 Redis技术交流群2 14 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-25.log: -------------------------------------------------------------------------------- 1 | 2019-07-25 18:24:12,375 Records log has been rotating... 2 | 2019-07-25 18:24:12,374 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-26.log: -------------------------------------------------------------------------------- 1 | 2019-07-26 11:36:54,486 Records log has been rotating... 2 | 2019-07-26 11:36:54,485 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-27.log: -------------------------------------------------------------------------------- 1 | 2019-07-27 08:34:56,778 Records log has been rotating... 2 | 2019-07-27 08:34:56,777 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-29.log: -------------------------------------------------------------------------------- 1 | 2019-07-29 17:07:22,180 Records log has been rotating... 2 | 2019-07-29 17:07:22,176 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-30.log: -------------------------------------------------------------------------------- 1 | 2019-07-30 06:36:12,600 Records log has been rotating... 2 | 2019-07-30 06:36:12,600 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-07-31.log: -------------------------------------------------------------------------------- 1 | 2019-07-31 09:44:53,258 Records log has been rotating... 2 | 2019-07-31 09:44:53,258 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-01.log: -------------------------------------------------------------------------------- 1 | 2019-08-01 09:15:58,962 Records log has been rotating... 2 | 2019-08-01 09:15:58,962 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-02.log: -------------------------------------------------------------------------------- 1 | 2019-08-02 07:44:39,441 Records log has been rotating... 2 | 2019-08-02 07:44:39,440 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-03.log: -------------------------------------------------------------------------------- 1 | 2019-08-03 20:27:37,827 Records log has been rotating... 2 | 2019-08-03 20:27:37,824 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-05.log: -------------------------------------------------------------------------------- 1 | 2019-08-05 08:04:19,689 Records log has been rotating... 2 | 2019-08-05 08:04:19,673 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-06.log: -------------------------------------------------------------------------------- 1 | 2019-08-06 11:29:40,592 Records log has been rotating... 2 | 2019-08-06 11:29:40,591 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-07.log: -------------------------------------------------------------------------------- 1 | 2019-08-07 08:18:27,028 Records log has been rotating... 2 | 2019-08-07 08:18:27,027 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-08.log: -------------------------------------------------------------------------------- 1 | 2019-08-08 16:05:06,523 Records log has been rotating... 2 | 2019-08-08 16:05:06,523 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-09.log: -------------------------------------------------------------------------------- 1 | 2019-08-09 09:43:43,806 Records log has been rotating... 2 | 2019-08-09 09:43:43,802 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-11.log: -------------------------------------------------------------------------------- 1 | 2019-08-11 13:36:29,134 Records log has been rotating... 2 | 2019-08-11 13:36:29,134 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-12.log: -------------------------------------------------------------------------------- 1 | 2019-08-12 00:06:11,624 Records log has been rotating... 2 | 2019-08-12 00:06:11,623 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-13.log: -------------------------------------------------------------------------------- 1 | 2019-08-13 07:54:12,515 Records log has been rotating... 2 | 2019-08-13 07:54:12,514 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-14.log: -------------------------------------------------------------------------------- 1 | 2019-08-14 07:48:28,914 Records log has been rotating... 2 | 2019-08-14 07:48:28,913 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-16.log: -------------------------------------------------------------------------------- 1 | 2019-08-16 16:16:55,087 Records log has been rotating... 2 | 2019-08-16 16:16:55,086 正在监测的群聊：2 个 3 | 2019-08-16 16:17:02,914 Redis技术交流群2 Redis技术交流群 4 | 2019-08-16 16:17:18,247 正在监测的群聊：3 个 5 | 2019-08-16 16:17:18,248 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 6 | 2019-08-16 16:27:12,633 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-19.log: -------------------------------------------------------------------------------- 1 | 2019-08-19 08:34:27,771 Records log has been rotating... 2 | 2019-08-19 08:34:27,765 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-20.log: -------------------------------------------------------------------------------- 1 | 2019-08-20 11:44:54,974 Records log has been rotating... 2 | 2019-08-20 11:44:54,973 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-21.log: -------------------------------------------------------------------------------- 1 | 2019-08-21 06:58:34,172 Records log has been rotating... 2 | 2019-08-21 06:58:34,172 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-23.log: -------------------------------------------------------------------------------- 1 | 2019-08-23 23:38:01,009 Records log has been rotating... 2 | 2019-08-23 23:38:00,994 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-25.log: -------------------------------------------------------------------------------- 1 | 2019-08-25 10:04:51,338 Records log has been rotating... 2 | 2019-08-25 10:04:51,337 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-27.log: -------------------------------------------------------------------------------- 1 | 2019-08-27 17:41:00,225 Records log has been rotating... 2 | 2019-08-27 17:41:00,194 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-28.log: -------------------------------------------------------------------------------- 1 | 2019-08-28 09:02:20,324 Records log has been rotating... 2 | 2019-08-28 09:02:20,323 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-08-30.log: -------------------------------------------------------------------------------- 1 | 2019-08-30 17:11:53,711 Records log has been rotating... 2 | 2019-08-30 17:11:53,710 正在监测的群聊：3 个 3 | 2019-08-30 17:12:00,050 Redis技术交流群3 Redis技术交流群2 Redis技术交流群 4 | 2019-08-30 17:12:10,885 正在监测的群聊：3 个 5 | 2019-08-30 17:12:10,886 Redis技术交流群3 Redis技术交流群2 Redis技术交流群 6 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-09-03.log: -------------------------------------------------------------------------------- 1 | 2019-09-03 21:42:54,499 Records log has been rotating... 2 | 2019-09-03 21:42:54,498 正在监测的群聊：2 个 3 | 2019-09-03 21:43:00,893 Redis技术交流群2 Redis技术交流群 4 | 2019-09-03 21:43:17,275 正在监测的群聊：2 个 5 | 2019-09-03 21:43:17,275 Redis技术交流群2 Redis技术交流群 6 | 2019-09-03 21:43:28,607 Records log has been rotating... 7 | 2019-09-03 21:47:10,980 正在监测的群聊：3 个 8 | 2019-09-03 21:47:10,981 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 9 | 2019-09-03 21:48:19,538 正在监测的群聊：3 个 10 | 2019-09-03 21:48:19,538 Redis技术交流群3 Redis技术交流群 Redis技术交流群2 11 | 2019-09-03 21:48:39,610 正在监测的群聊：3 个 12 | 2019-09-03 21:48:39,611 Redis技术交流群3 Redis技术交流群 Redis技术交流群2 13 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-09-07.log: -------------------------------------------------------------------------------- 1 | 2019-09-07 22:46:59,701 Records log has been rotating... 2 | 2019-09-07 22:46:59,700 正在监测的群聊：2 个 3 | 2019-09-07 22:47:05,934 Redis技术交流群 Redis技术交流群2 4 | 2019-09-07 22:47:18,818 正在监测的群聊：2 个 5 | 2019-09-07 22:47:18,818 Redis技术交流群 Redis技术交流群2 6 | 2019-09-07 22:51:06,521 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-09-08.log: -------------------------------------------------------------------------------- 1 | 2019-09-08 08:02:53,539 Records log has been rotating... 2 | 2019-09-08 08:02:53,539 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-09-19.log: -------------------------------------------------------------------------------- 1 | 2019-09-19 13:59:21,714 Records log has been rotating... 2 | 2019-09-19 13:59:21,714 正在监测的群聊：2 个 3 | 2019-09-19 13:59:27,056 Redis技术交流群 Redis技术交流群2 4 | 2019-09-19 14:00:31,655 正在监测的群聊：2 个 5 | 2019-09-19 14:00:31,656 Redis技术交流群 Redis技术交流群2 6 | 2019-09-19 14:01:06,773 正在监测的群聊：2 个 7 | 2019-09-19 14:01:06,774 Redis技术交流群 Redis技术交流群2 8 | 2019-09-19 14:02:00,038 正在监测的群聊：2 个 9 | 2019-09-19 14:02:00,039 Redis技术交流群 Redis技术交流群2 10 | 2019-09-19 14:02:34,181 正在监测的群聊：2 个 11 | 2019-09-19 14:02:34,181 Redis技术交流群 Redis技术交流群2 12 | 2019-09-19 14:05:18,967 正在监测的群聊：3 个 13 | 2019-09-19 14:05:18,967 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 14 | 2019-09-19 14:06:37,735 正在监测的群聊：3 个 15 | 2019-09-19 14:06:37,735 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 16 | 2019-09-19 14:08:37,201 Records log has been rotating... 17 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-10-11.log: -------------------------------------------------------------------------------- 1 | 2019-09-20 09:55:43,912 Records log has been rotating... 2 | 2019-09-20 09:55:43,911 Records log has been rotating... 3 | 2019-10-11 03:22:26,638 正在监测的群聊：2 个 4 | 2019-10-11 03:22:26,685 Redis技术交流群2 Redis技术交流群 5 | 2019-10-11 03:24:53,238 正在监测的群聊：2 个 6 | 2019-10-11 03:24:53,238 Redis技术交流群2 Redis技术交流群 7 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-10-14.log: -------------------------------------------------------------------------------- 1 | 2019-10-14 07:21:57,542 Records log has been rotating... 2 | 2019-10-14 07:21:57,542 正在监测的群聊：3 个 3 | 2019-10-14 07:22:12,187 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 4 | 2019-10-14 07:22:25,291 正在监测的群聊：3 个 5 | 2019-10-14 07:22:25,291 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 6 | 2019-10-14 07:23:06,767 Records log has been rotating... 7 | 2019-10-14 07:25:06,735 正在监测的群聊：3 个 8 | 2019-10-14 07:25:06,736 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 9 | 2019-10-14 07:25:22,638 正在监测的群聊：3 个 10 | 2019-10-14 07:25:22,644 Redis技术交流群2 Redis技术交流群 Redis技术交流群3 11 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-10-15.log: -------------------------------------------------------------------------------- 1 | 2019-10-15 12:26:21,288 Records log has been rotating... 2 | 2019-10-15 12:26:21,287 正在监测的群聊：3 个 3 | 2019-10-15 12:26:33,080 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 4 | 2019-10-15 12:26:41,284 正在监测的群聊：3 个 5 | 2019-10-15 12:26:41,286 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 6 | 2019-10-15 12:26:56,076 正在监测的群聊：3 个 7 | 2019-10-15 12:26:56,077 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 8 | 2019-10-15 12:27:38,145 Records log has been rotating... 9 | 2019-10-15 12:29:46,115 正在监测的群聊：3 个 10 | 2019-10-15 12:29:46,115 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 11 | 2019-10-15 12:32:39,328 正在监测的群聊：3 个 12 | 2019-10-15 12:32:39,329 Redis技术交流群 Redis技术交流群2 Redis技术交流群3 13 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-10-16.log: -------------------------------------------------------------------------------- 1 | 2019-10-16 00:07:07,118 Records log has been rotating... 2 | 2019-10-16 00:07:07,117 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-10-17.log: -------------------------------------------------------------------------------- 1 | 2019-10-17 00:09:40,268 Records log has been rotating... 2 | 2019-10-17 00:09:40,267 Records log has been rotating... 3 | -------------------------------------------------------------------------------- /ChatRecords/main.2019-12-31.log: -------------------------------------------------------------------------------- 1 | 2019-12-31 09:40:36,614 正在监测的群聊：2 个 2 | 2019-12-31 09:40:36,614 Redis技术交流群 Redis技术交流群2 3 | 2019-12-31 09:40:43,476 正在监测的群聊：2 个 4 | 2019-12-31 09:40:43,476 Redis技术交流群 Redis技术交流群2 5 | -------------------------------------------------------------------------------- /ChatRecords/main.2020-01-02.log: -------------------------------------------------------------------------------- 1 | 2020-01-01 22:05:06,152 Records log has been rotating... 2 | 2020-01-01 22:05:06,152 正在监测的群聊：2 个 3 | 2020-01-01 22:05:08,573 Redis技术交流群 Redis技术交流群2 4 | 2019-12-31 09:40:36,614 正在监测的群聊：2 个 5 | 2019-12-31 09:40:36,614 Redis技术交流群 Redis技术交流群2 6 | 2019-12-31 09:40:43,476 正在监测的群聊：2 个 7 | 2019-12-31 09:40:43,476 Redis技术交流群 Redis技术交流群2 8 | 2019-12-31 01:41:41,520 正在监测的群聊：2 个 9 | 2019-12-31 01:41:41,520 Redis技术交流群 Redis技术交流群2 10 | 2020-01-02 14:40:07,626 正在监测的群聊：2 个 11 | 2020-01-02 14:40:07,626 Redis技术交流群 Redis技术交流群2 12 | 2020-01-02 15:44:58,370 正在监测的群聊：2 个 13 | 2020-01-02 15:44:58,370 Redis技术交流群 Redis技术交流群2 14 | -------------------------------------------------------------------------------- /ChatRecords/main.2020-01-03.log: -------------------------------------------------------------------------------- 1 | 2020-01-03 07:27:14,811 Records log has been rotating... 2 | 2020-01-03 07:27:14,810 正在监测的群聊：2 个 3 | 2020-01-03 07:27:19,440 Redis技术交流群 Redis技术交流群2 4 | 2020-01-03 07:27:30,193 正在监测的群聊：2 个 5 | 2020-01-03 07:27:30,194 Redis技术交流群 Redis技术交流群2 6 | 2020-01-03 12:08:45,183 Records log has been rotating... 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/redisgroup -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-21.log: -------------------------------------------------------------------------------- 1 | 2019-04-21 10:07:57,005 鹏程@CMBC from Redis技术交流群 分享链接: 2 | #每日分享 「链接」 Understanding the Failover Mechanism of Redis Cluster - Alibaba Cloud Community 3 | https://t.zsxq.com/nuJ6mEA 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-24.log: -------------------------------------------------------------------------------- 1 | 2019-04-24 07:13:48,864 白馨@陌陌 说: 2 | 不好意思，当时没看清楚，领了红包 3 | 2019-04-24 07:14:06,808 周淼@育儿网 说: 4 | what 5 | 2019-04-24 07:16:55,100 周淼@育儿网 说: 6 | 看懂了，去不了了 7 | 2019-04-24 08:18:48,016 姜皓楠@aliyun 说: 8 | @白馨@陌陌  这，不用这么认真的好吧 [捂脸][捂脸][捂脸] 玩笑话而已，大家都挺忙，能抽空看看直播就很感谢了，没时间也是理解的 9 | 2019-04-24 08:21:01,798 白馨@陌陌 说: 10 | 下次有别的分享一定去看[强][强][强] 11 | 2019-04-24 11:21:58,318 鹏程@CMBC 分享链接: 12 | #每日分享 「链接」 In-depth Analysis of Redis Cluster Gossip Protocol... 13 | https://t.zsxq.com/biAuJMz 14 | 2019-04-24 16:18:25,879 Jason 说: 15 | redis有异地双活的架构不 16 | 2019-04-24 16:22:04,258 鹏程@CMBC 说: 17 | @Jason 亲 改下群名片 18 | 2019-04-24 17:12:47,037 HQ@TAL 说: 19 | redis sdiff 集合可以是对象吗？ 20 | 2019-04-24 18:43:04,962 Mitol@stream 说: 21 | 都只是string的比较才对，你说的对象是序列化后的字符串 22 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-26.log: -------------------------------------------------------------------------------- 1 | 2019-04-26 10:32:53,691 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 AOF for Redis Persistence | Develop Paper 3 | https://t.zsxq.com/fq7MjeU 4 | 2019-04-26 11:21:56,113 黄威@国美 说: 5 | redis中如果使用epoll作为ae的底层话，使用的是水平触发模式 6 | 2019-04-26 11:23:27,854 黄威@国美 说: 7 | 函数调用链networking.c/creatClient->ae.c/aeCreateFileEvent 8 | 2019-04-26 11:25:01,944 黄威@国美 说: 9 | AE_READABLE为1，EPOLLET为1u<<31 10 | 2019-04-26 11:26:26,583 黄威@国美 说: 11 | 抱歉，少写了个函数，networking.c/creatClient->ae.c/aeCreateFileEvent->ae_epoll.c/aeApiAddEvent 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-27.log: -------------------------------------------------------------------------------- 1 | 2019-04-27 07:45:50,144 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 如何解决Redis中的key过期问题 3 | https://t.zsxq.com/MFEMjuZ 4 | 2019-04-27 13:07:16,677 Glenn@美团点评 说: 5 | @鹏程@CMBC 鹏程 作者是不是有篇博客来说redis的性能瓶颈不在cpu 还是在网络io？ 6 | 2019-04-27 13:10:20,156 鹏程@CMBC 说: 7 | 这篇文章是译作 8 | 2019-04-27 13:11:35,677 Glenn@美团点评 说: 9 | 有连接吗 10 | 2019-04-27 13:16:25,464 白馨@陌陌 说: 11 | 以前阿里云好像改过一版，网络io用多线程来做。 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-28.log: -------------------------------------------------------------------------------- 1 | 2019-04-28 17:17:10,899 Xiaff🐣@maike 说: 2 | 大神么使用redis的过程中遇到过这个问题么 3 | 2019-04-28 17:17:40,720 Xiaff🐣@maike 说: 4 | 初步推测这个ok是redis中的ok 5 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-04-29.log: -------------------------------------------------------------------------------- 1 | 2019-04-29 06:55:04,290 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 分布式并发场景下SpringSession(Redis) 的数据脏读问题 | Develop Pap... 3 | https://t.zsxq.com/i6U3NFM 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-01.log: -------------------------------------------------------------------------------- 1 | 2019-05-01 22:59:21,762 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 【Redis源码研究】Redis的一个历史bug及其后续改进 - 个人文章 - SegmentFau... 3 | https://t.zsxq.com/meaUFeM 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-03.log: -------------------------------------------------------------------------------- 1 | 2019-05-03 07:50:02,300 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 https://youtu.be/hRxWAqU2BHE 3 | https://t.zsxq.com/zVJUzJM 4 | 2019-05-03 15:10:22,684 Rui Gu@Redisson 说: 5 | @鹏程@CMBC 想了解一下群里面有很多人在生产用Redisson，能帮过忙吗？ 6 | 2019-05-03 15:10:52,393 Slogen@didi 说: 7 | 我们线上用了@Rui Gu@Redisson  8 | 2019-05-03 15:11:54,641 Rui Gu@Redisson 说: 9 | [强][强]感谢你们的支持和信任 10 | 2019-05-03 15:11:58,699 Rui Gu@Redisson 说: 11 | @Slogen@didi  12 | 2019-05-03 15:14:13,885 鹏程@CMBC 说: 13 | @Rui Gu@Redisson 想了解一下群里面有很多人在生产用Redisson，大家谁用的举个手~ @所有人 14 | 2019-05-03 15:14:24,699 鹏程@CMBC 说: 15 | @Rui Gu@Redisson 想了解一下群里面有很多人在生产用Redisson，大家谁用的举个手~ @所有人 16 | 2019-05-03 15:37:36,116 何铁头@wl 说: 17 | 打算线上使用，还在测试 18 | 2019-05-03 15:41:11,526 goddie@汇量科技 说: 19 | 我们没用，用的redis和aerospike 20 | 2019-05-03 15:46:05,908 张晋涛@网易 说: 21 | 有业务在测试 印象中没上生产 22 | 2019-05-03 16:15:06,917 Rui Gu@Redisson 说: 23 | @何铁头@wl 你们是哪个公司？ 24 | 2019-05-03 16:25:20,768 Rui Gu@Redisson 说: 25 | @鹏程@CMBC 我才想起，现在是五一放假期间 26 | 2019-05-03 16:26:04,533 鹏程@CMBC 说: 27 | 是 28 | 2019-05-03 16:26:25,314 Rui Gu@Redisson 说: 29 | [捂脸] 30 | 2019-05-03 16:26:46,368 Rui Gu@Redisson 说: 31 | 看来只有我在苦逼上班 32 | 2019-05-03 16:27:25,759 何铁头@wl 说: 33 | 车点点 34 | 2019-05-03 16:28:29,586 Rui Gu@Redisson 说: 35 | [握手][握手] 36 | 2019-05-03 17:04:13,938 东风无眠@华泰证券 说: 37 | 有人试过redis对ipv6支持不 38 | 2019-05-03 17:21:15,742 柱星同学@pytc 说: 39 | redis支持ipv6，应该是2.8版本之后。 40 | jedis 2.9.0以上版本客户端支持ipv6 @东风无眠@华泰证券 其他smartclient 不清楚了 41 | 2019-05-03 17:50:02,101 东风无眠@华泰证券 说: 42 | @柱星同学@pytc 有这个错误 43 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-04.log: -------------------------------------------------------------------------------- 1 | 2019-05-04 08:45:39,486 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 https://youtu.be/9hFCOXJd1yg 3 | https://t.zsxq.com/aYJ2fiM 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-06.log: -------------------------------------------------------------------------------- 1 | 2019-05-06 01:03:30,125 Rui Gu@Redisson 说: 2 | @黄建@友塔游戏 客户端订阅哨兵的变化，客户端就能感知到变化了 3 | 2019-05-06 06:55:38,192 鹏程@CMBC 分享链接: 4 | #每日分享 「链接」 Redis在微服务架构中的几种应用场景 - 掘金 5 | https://t.zsxq.com/IYn23j2 6 | 2019-05-06 09:55:32,967 steven 说: 7 | http://dtcc.it168.com/yicheng.html?from=timeline 8 | 2019-05-06 09:55:33,835 steven 说: 9 | 400有需要加我 10 | 2019-05-06 10:42:19,824 黄建@友塔游戏 说: 11 | @Rui Gu@Redisson 嗯好的，看来单机多实例，想要做到服务端无感知还需要别的工具来做。 12 | 2019-05-06 10:56:53,355 鹏程@CMBC 说: 13 | @steven 无关话题 14 | 2019-05-06 11:43:49,973 (o^^o)@中体彩 说: 15 | 师兄们有人熟悉mongodb的吗 16 | 2019-05-06 11:56:37,839 Victor 说: 17 | 直接问问题 18 | 2019-05-06 12:30:04,837 鹏程@CMBC 说: 19 | @(o^^o)@中体彩 无关话题 20 | 2019-05-06 12:31:13,723 (o^^o)@中体彩 说: 21 | @Victor 刚用mongo，遇到的问题是，加完用户，启动认证登陆后，副本集群直接recovering，日志里显示没有权限执行心跳检测，问下，这个情况是少什么权限么 22 | 2019-05-06 12:31:30,692 (o^^o)@中体彩 说: 23 | @鹏程@CMBC 好的，下次会注意 24 | 2019-05-06 12:33:51,526 鹏程@CMBC 说: 25 | @(o^^o)@中体彩 看群规哈~ 26 | 2019-05-06 12:39:56,583 Victor 说: 27 | @(o^^o)@中体彩 没碰到过 28 | 2019-05-06 12:59:00,581 秦亚男@lagou 说: 29 | 看看是不是auth key没配置，mongodb官网写的很详细。对照看下你是不是少做了哪一项。@victor 30 | 2019-05-06 13:00:14,904 秦亚男@lagou 说: 31 | 像是auth key没配置，mongodb官网写的很详细。对照看下你是不是少做了哪一项。@(o^^o)@中体彩 32 | 2019-05-06 13:04:15,382 (o^^o)@中体彩 说: 33 | @Victor @秦亚男@lagou 好的，谢谢 34 | 2019-05-06 19:55:00,191 Slogen@didi 说: 35 | @Rui Gu@Redisson hi 大神，想问下redisson客户端的连接池默认限制多少啊 36 | 2019-05-06 21:46:53,396 Rui Gu@Redisson 说: 37 | @Slogen@didi 版本不同默认数量不一样，之前改过两次。你看看对应的Config。 38 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-07.log: -------------------------------------------------------------------------------- 1 | 2019-05-07 09:48:03,259 Slogen@didi 说: 2 | @Rui Gu@Redisson hi. 我们线上redisson报错 3 | 2019-05-07 09:48:15,387 Slogen@didi 说: 4 | 什么情况下会报这个错啊 5 | 2019-05-07 09:48:28,334 Slogen@didi 说: 6 | org.redisson.client.RedisTimeoutException: Unable to send command! Node source: NodeSource 7 | 2019-05-07 14:51:18,521 Rui Gu@Redisson 说: 8 | @Slogen@didi 连接数不够 9 | 2019-05-07 15:27:20,916 Slogen@didi 说: 10 | 线上什么都没改，流量也没发生变化，突然就出现这个情况，https://www.cnblogs.com/junge8618/p/9241927.html 跟这个文章里面描述的差不多 11 | 2019-05-07 15:27:33,872 Slogen@didi 说: 12 | 升级了redisson版本，就OK了 13 | 2019-05-07 15:28:18,499 Slogen@didi 说: 14 | 升级到了3.10.6 15 | 2019-05-07 15:29:01,260 Rui Gu@Redisson 说: 16 | @Slogen@didi 他的原因是远程主机强迫关闭了一个现有的连接 17 | 2019-05-07 15:30:10,643 Rui Gu@Redisson 说: 18 | 是因为长时间没有消息发送，防火墙把连接断了 19 | 2019-05-07 15:30:42,786 Slogen@didi 说: 20 | 但是我们的代码里面是在一个定时任务里面去redis获取数据，1.5s执行一次 21 | 2019-05-07 15:30:44,163 Rui Gu@Redisson 说: 22 | 你也是这个问题吗？ 23 | 2019-05-07 15:31:42,489 Rui Gu@Redisson 说: 24 | 并大量多大？ 25 | 2019-05-07 19:58:49,120 伍旭飞@腾讯 说: 26 | @Rui Gu@Redisson 这个一旦连接断开，不会踢掉或者重连吗 27 | 2019-05-07 19:59:24,148 Rui Gu@Redisson 说: 28 | @伍旭飞@腾讯 你说的是@Slogen@didi 的问题？ 29 | 2019-05-07 20:15:01,706 伍旭飞@腾讯 说: 30 | 对 31 | 2019-05-07 20:19:08,475 邓伟@jit 说: 32 | 即使定时维持连接，也会有其他原因完成网络中断 33 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-12.log: -------------------------------------------------------------------------------- 1 | 2019-05-12 10:37:38,557 鹏程@CMBC 分享链接: 2 | Benchmarking the experimental Redis Multi-Threaded I/O 3 | https://itnext.io/benchmarking-the-experimental-redis-multi-threaded-i-o-1bb28b69a314 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-13.log: -------------------------------------------------------------------------------- 1 | 2019-05-13 08:03:11,143 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 How we migrated aws elasticache (redis) cluster to... 3 | https://t.zsxq.com/Y7qNf2F 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-15.log: -------------------------------------------------------------------------------- 1 | 2019-05-15 13:22:23,185 Glenn@美团点评 说: 2 | 我测试极端降低50%以上 主要看业务场景 3 | 2019-05-15 13:23:26,464 鹏程@CMBC 说: 4 | 这么多？ 5 | 2019-05-15 13:24:35,361 Rui Gu@Redisson 说: 6 | 晕。。 7 | 2019-05-15 13:28:56,915 白馨@陌陌 说: 8 | 😳 9 | 2019-05-15 22:06:40,555 鹏程@CMBC 分享链接: 10 | #每日分享 「链接」 Azure Cache for Redis FAQ | Microsoft Docs 11 | https://t.zsxq.com/qrVNFyJ 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-16.log: -------------------------------------------------------------------------------- 1 | 2019-05-16 03:03:23,357 邵佳琪@bilibili 说: 2 | @Glenn@美团点评 请教下 昨天说的inter cpu 补丁影响 redis性能和业务场景有关指的是？ 3 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-17.log: -------------------------------------------------------------------------------- 1 | 2019-05-17 06:59:44,589 鹏程@CMBC 说: 2 | 嗯，早就有了 3 | 2019-05-17 07:01:54,735 北极冷啊BG5FLH@yanji 说: 4 | Redis 会将整个脚本作为一个整体执行，中间不会被其他命令插入。无需担心会出现竞态条件，无须使用事务。 5 | 2019-05-17 07:12:55,454 海涛@SPDB 说: 6 | @北极冷啊BG5FLH@yanji 整体执行不代表是原子的吧 7 | 2019-05-17 07:17:43,396 北极冷啊BG5FLH@yanji 说: 8 | 一个整体可以看成是原子的 失败会回滚的 9 | 2019-05-17 07:18:39,750 北极冷啊BG5FLH@yanji 说: 10 | 脚本之间是隔离的 11 | 2019-05-17 14:43:00,223 (o^^o)@中体彩 说: 12 | 问下，redis cluster集群故障自动恢复，是不是只能用哨兵的方式，必须master挂了，slave自动升级 13 | 2019-05-17 15:30:11,426 东风无眠@华泰证券 说: 14 | cluster自己就能恢复，不需要哨兵 15 | 2019-05-17 15:44:26,376 (o^^o)@中体彩 说: 16 | 今天测试了下，直接kill掉一个master节点，slave节点一直没有升级，不知道为啥，cluster-slave-validity-factor这个值也设置了 17 | 2019-05-17 18:15:01,688 国清@Microsoft 说: 18 | 几个master？cluster info 说的啥 19 | 2019-05-17 18:19:50,225 晓晨@头条 说: 20 | Master太少没办法投票的 21 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-19.log: -------------------------------------------------------------------------------- 1 | 2019-05-19 00:30:55,729 黄靖凯@华为云 说: 2 | @余汶龙@滴滴 成本降低主要在自研ARM的整合，比X86优势明显太多；提升资源利用率，可售卖内存变多，解决高内存负载运行下Redis持久化的麻烦问题，减少系统资源、预留内存 3 | 2019-05-19 00:31:46,582 张冬洪@CRUG 说: 4 | [强] 5 | 2019-05-19 00:33:58,440 黄靖凯@华为云 说: 6 | 不是PPT产品，已经诸多客户商用，价格官网可查。 7 | 测试数据不方便放太多，前两天有个A过黑名单事件，删除了很多对比数据，这块我们后续会有具体技术解读 8 | 2019-05-19 00:34:10,957 余汶龙@滴滴 说: 9 | [强] 10 | 2019-05-19 00:34:14,164 黄靖凯@华为云 说: 11 | 不是PPT产品，已经诸多客户商用，价格官网可查。 12 | 测试数据不方便放太多，前两天有个A国黑名单事件，删除了很多对比数据，这块我们后续会有具体技术解读 13 | 2019-05-19 00:41:25,344 刘乐＠多来点 说: 14 | [强][强][强] 15 | 2019-05-19 00:42:59,107 黄靖凯@华为云 说: 16 | 半年前之前Linux之父 linus与Redis作者antirez，在X86和ARM上能力有争议。 17 | 我们现在这两块能力都支持，优缺点都很了解，加了很多黑科技为了弥补ARM当前存在的一些不足，包括性能、稳定性等能力，否则无法给客户商用 18 | 2019-05-19 00:44:26,424 黄靖凯@华为云 分享链接: 19 | It's extremely hard to agree with Linus on that. One problem in his argument is ... | Hacker News 20 | https://news.ycombinator.com/item?id=19225678 21 | 2019-05-19 03:05:23,083 叶翔@阿里云 说: 22 | @黄靖凯@华为云 咱们的arm是多少core的啊 23 | 2019-05-19 03:19:07,607 鹏程@CMBC 说: 24 | @黄华亮@vivo 已确认 25 | 2019-05-19 03:19:42,908 鹏程@CMBC 说: 26 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @BlackMoon 27 | 2019-05-19 03:20:00,651 隋巍@华为 说: 28 | 已改 29 | 2019-05-19 04:47:13,507 黄靖凯@华为云 说: 30 | @叶翔@阿里云 Core比X86要多 31 | 2019-05-19 07:14:42,282 小王@西安 说: 32 | 请问有比较常见的redis和其他数据库结合做缓存的落地方案吗？ 比如redis+hbase， redis+mysql。 33 | 2019-05-19 23:17:37,916 鹏程@CMBC 分享链接: 34 | #每日分享 「链接」 Introducing the Redis-full-check Tool - Alibaba Cl... 35 | https://t.zsxq.com/6UNZFma 36 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-21.log: -------------------------------------------------------------------------------- 1 | 2019-05-21 00:42:18,477 杭州—小华 说: 2 | [强] 3 | 2019-05-21 08:42:57,147 张晋涛@网易 说: 4 | cluster 么 那用 go redis cluster 5 | 2019-05-21 08:43:31,605 张晋涛@网易 说: 6 | 基于 redigo 实现的 cluster 集群支持 7 | 2019-05-21 08:47:08,981 YZz 说: 8 | 嗯嗯 9 | 2019-05-21 10:54:52,005 鹏程@CMBC 分享链接: 10 | #每日分享 「链接」 Tedis：基于 TiKV 构建的 NoSQL 数据库 11 | https://t.zsxq.com/7aY37Ia 12 | 2019-05-21 10:55:19,894 鹏程@CMBC 说: 13 | @陈东明@饿了么 14 | 2019-05-21 10:55:23,078 鹏程@CMBC 说: 15 | 大作 16 | 2019-05-21 10:55:40,738 余汶龙@滴滴 说: 17 | [强] 18 | 2019-05-21 10:56:22,894 李航@滴滴 说: 19 | [强] 20 | 2019-05-21 10:56:34,738 Rui Gu@Redisson 说: 21 | [强] 22 | 2019-05-21 10:56:43,645 王江华@好未来 说: 23 | [强] 24 | 2019-05-21 10:56:56,454 陈东明@饿了么 说: 25 | @鹏程@CMBC 还比较简陋，多提意见 26 | 2019-05-21 10:57:01,539 强昌金@极数云舟 说: 27 | [强] 28 | 2019-05-21 11:25:38,524 张皓_小作坊棋牌 说: 29 | [强] 30 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-22.log: -------------------------------------------------------------------------------- 1 | 2019-05-22 10:01:22,840 鹏程@CMBC 说: 2 | @所有人 征集下，大家知道包括国内外以及云厂商在内的厂子谁做了Redis灾备和同城异地灾备的？ 3 | 2019-05-22 10:01:31,281 鹏程@CMBC 说: 4 | @所有人 征集下，大家知道包括国内外以及云厂商在内的厂子谁做了Redis灾备和同城异地灾备的？ 5 | 2019-05-22 10:01:43,610 Rui Gu@Redisson 说: 6 | Aliyun RedisLabs 7 | 2019-05-22 10:01:52,885 刘洋@阿里云 说: 8 | 阿里云啊 9 | 2019-05-22 10:01:58,805 鹏程@CMBC 说: 10 | 还有腾讯云 11 | 2019-05-22 10:02:01,842 鹏程@CMBC 说: 12 | 携程 13 | 2019-05-22 10:02:07,923 鹏程@CMBC 说: 14 | 饿了么是不是也有？ 15 | 2019-05-22 10:02:24,842 Rui Gu@Redisson 说: 16 | 异地多活好像就这两家 17 | 2019-05-22 10:03:01,495 鹏程@CMBC 说: 18 | @刘冬@头条 头条有吗？ 19 | 2019-05-22 10:06:23,655 鹏程@CMBC 说: 20 | @国清@Microsoft Azure有吗 21 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-23.log: -------------------------------------------------------------------------------- 1 | 2019-05-23 11:40:18,334 tomato@沃趣 说: 2 | 请教一个问题，大量key过期会导致qps卡顿，同时cpu不高的情况吗，有人碰到过吗？ 3 | 2019-05-23 11:41:02,378 tomato@沃趣 说: 4 | 只是简单kv,不存在hash set list 5 | 2019-05-23 11:41:29,380 解奕晨@京东 说: 6 | hi，我想通过info命令里的master_repl_offset和slave的offset两个值的差实现以下对redis-2.8主从同步延迟情况的监控，我理解主的偏移值应该一直大于等于从的偏移值，但是现在发现有一些实例一直会出现从的偏移值大于主的偏移值，有人知道这是为什么吗？ 7 | 8 | 2019-05-23 11:41:29,767 解奕晨@京东 说: 9 | 10 | 比如这个实例从的偏移值总是比主的大140 11 | 求解答 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-25.log: -------------------------------------------------------------------------------- 1 | 2019-05-25 06:29:28,269 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 bilibili 缓存解决方案（一）： overlord-platform介绍 3 | https://t.zsxq.com/iaY3bQb 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-26.log: -------------------------------------------------------------------------------- 1 | 2019-05-26 07:34:15,466 鹏程@CMBC 说: 2 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @stuart 3 | 2019-05-26 07:35:40,878 鹏程@CMBC 分享链接: 4 | Python高性能编程 5 | https://www.douban.com/doubanapp/dispatch/book/27064848?dt_platform=wechat_friends&dt_dapp=1 6 | 2019-05-26 07:36:58,256 鹏程@CMBC 分享链接: 7 | 分布式对象存储 8 | https://www.douban.com/doubanapp/dispatch/book/30252598?dt_platform=wechat_friends&dt_dapp=1 9 | 2019-05-26 07:37:22,219 鹏程@CMBC 说: 10 | @stuart@improbable 胡总是这几本的作者 11 | 2019-05-26 07:37:45,219 stuart@improbable 说: 12 | 大家好，一起交流共同进步 13 | 2019-05-26 07:38:01,585 周淼@育儿网 说: 14 | 欢迎大佬 15 | 2019-05-26 07:39:09,768 王江华@好未来 说: 16 | 欢迎大佬 17 | 2019-05-26 08:41:09,227 魏海涛@新华社 说: 18 | 欢迎大佬 19 | 2019-05-26 14:19:56,823 Glenn@美团点评 说: 20 | 欢迎大佬 21 | 2019-05-26 14:22:07,727 小智@高顿 说: 22 | 欢迎大佬 23 | 2019-05-26 14:25:06,521 Slogen@didi 说: 24 | 欢迎大大佬 25 | 2019-05-26 23:54:11,232 鹏程@CMBC 分享链接: 26 | #每日分享 「链接」 GitHub - oliver006/redis_exporter: Prometheus Expo... 27 | https://t.zsxq.com/NvrrJIy 28 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-27.log: -------------------------------------------------------------------------------- 1 | 2019-05-27 17:47:27,317 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Building a real-time word cloud from Twitch.tv chat with Node.js and Redis 3 | https://t.zsxq.com/bQVrbYR 4 | 2019-05-27 17:55:51,492 晓.峰@陆金所 说: 5 | [强] 6 | 2019-05-27 18:03:16,766 石京海@ApacheOFBiz 说: 7 | 俺打不开最后这个啊 8 | 2019-05-27 18:08:39,922 鹏程@CMBC 说: 9 | Medium 10 | 2019-05-27 18:08:46,945 鹏程@CMBC 说: 11 | 翻墙 12 | 2019-05-27 23:35:25,706 黄威@国美 说: 13 | [强] 14 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-28.log: -------------------------------------------------------------------------------- 1 | 2019-05-28 05:58:50,169 唐唐@烽火 说: 2 | 请问，Redis中有没有办法知道一个键已经存在了多长时间了？(键没有设置过期时间) 3 | 2019-05-28 06:01:12,042 Akkadian@神器 说: 4 | [抠鼻]没有吧 5 | 2019-05-28 07:48:03,619 stuart@improbable 说: 6 | value带上时间戳 7 | 2019-05-28 08:11:50,831 陈雷@滴滴 说: 8 | https://segmentfault.com/a/1190000018878466 @张仕华@滴滴 这篇文章分析的很赞。 9 | 2019-05-28 08:18:12,167 张仕华@滴滴 说: 10 | [抱拳][抱拳] 11 | 2019-05-28 10:41:50,174 何强 说: 12 | @ら冬@微盟 hi，请问你是微盟的开发吗？ 13 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-29.log: -------------------------------------------------------------------------------- 1 | 2019-05-29 07:16:38,243 harry@同程旅游 说: 2 | Roaring bitmaps 3 | 2019-05-29 07:16:56,653 harry@同程旅游 说: 4 | 确认个问题 redis的bitmap 是这个算法的实现吗？ 5 | 2019-05-29 08:04:09,530 鹏程@CMBC 说: 6 | 看上下文好像不是？ 7 | 2019-05-29 08:04:10,430 鹏程@CMBC 说: 8 | https://github.com/antirez/redis/issues/271 9 | 2019-05-29 08:06:48,770 harry@同程旅游 说: 10 | redis bitmap 是512M 的大小，如果设置一个2的32次幕的position 会不会把512m全占上 11 | 2019-05-29 10:11:13,655 harry@同程旅游 说: 12 | https://www.elastic.co/cn/blog/frame-of-reference-and-roaring-bitmaps 13 | 2019-05-29 10:11:22,932 harry@同程旅游 说: 14 | es里用的是这个算法 15 | 2019-05-29 12:34:48,345 Rui Gu@Redisson 说: 16 | RedissonPRO里提供了这个的 17 | 2019-05-29 12:55:02,925 harry@同程旅游 说: 18 | 亲测 redis 自带这个 一下会吃掉512m 19 | 2019-05-29 12:58:00,270 harry@同程旅游 说: 20 | hysMem: 6708M used (1745M wired), 1482M unused. 21 | 2019-05-29 12:58:17,162 harry@同程旅游 说: 22 | PhysMem: 7223M used (1745M wired), 968M unuse 23 | 2019-05-29 12:58:26,064 harry@同程旅游 说: 24 | setbit a 4294967295 1 25 | 2019-05-29 12:58:35,701 harry@同程旅游 说: 26 | set 完之后的内存使用量 27 | 2019-05-29 12:58:55,991 harry@同程旅游 说: 28 | PhysMem: 6745M used (1747M wired), 1444M unuse 29 | 2019-05-29 12:59:00,222 harry@同程旅游 说: 30 | del a 31 | 2019-05-29 12:59:10,553 harry@同程旅游 说: 32 | del 之后的内存使用量 33 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-05-30.log: -------------------------------------------------------------------------------- 1 | 2019-05-30 00:03:12,971 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 马蜂窝ABTest多层分流系统的设计与实现 - 马蜂窝技术 - SegmentFault 思否 3 | https://t.zsxq.com/BIiaqRf 4 | 2019-05-30 09:08:50,771 鹏程@CMBC 说: 5 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @candy 6 | 2019-05-30 09:15:13,034 程浩 说: 7 | C++中国用户组，6/15号在杭州有个小型的，关于分布式一致性存储相关的技术交流， 有兴趣的小伙伴欢迎来聊聊。 https://www.slidestalk.com/m/34 8 | 2019-05-30 09:17:26,507 鹏程@CMBC 说: 9 | @程浩 无关话题 10 | 2019-05-30 09:17:56,876 程浩 说: 11 | 嗯嗯，抱歉啊，我补个红包 12 | 2019-05-30 09:18:41,144 鹏程@CMBC 说: 13 | @程浩 嗯嗯，改个群名片也~ 14 | 2019-05-30 09:18:51,537 程浩 说: 15 | 嗯嗯 16 | 2019-05-30 09:19:04,023 鹏程@CMBC 说: 17 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @Frankie 18 | 2019-05-30 09:20:32,867 Frankie 说: 19 | 好的，我叫周阳，国美架构部负责中间件缓存的研发 20 | 2019-05-30 09:21:11,670 Frankie 说: 21 | 请各位大佬指教啦 22 | 2019-05-30 09:24:18,003 张晋涛@网易 说: 23 | 欢迎 24 | 2019-05-30 09:24:32,186 王江华@好未来 说: 25 | 欢迎 26 | 2019-05-30 09:24:35,325 付磊@快手 说: 27 | 欢迎 28 | 2019-05-30 09:25:04,857 鹏程@CMBC 说: 29 | 欢迎 30 | 2019-05-30 09:27:06,414 邵佳琪@bilibili 说: 31 | 欢迎 32 | 2019-05-30 09:27:20,645 腾讯 谭铭波 说: 33 | [愉快] 34 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-01.log: -------------------------------------------------------------------------------- 1 | 2019-06-01 16:41:15,122 鹏程@CMBC 说: 2 | 群机器人恢复……最近大陆封ip太多了.. 3 | 2019-06-01 18:07:42,340 鹏程@CMBC 分享链接: 4 | #每日分享 「链接」 Redis中的LRU淘汰策略分析 5 | https://t.zsxq.com/EMRFMfQ 6 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-02.log: -------------------------------------------------------------------------------- 1 | 2019-06-02 03:18:11,664 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Configuring Redis using a ConfigMap - Kubernetes 3 | https://t.zsxq.com/iA6233F 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-04.log: -------------------------------------------------------------------------------- 1 | 2019-06-04 15:41:50,511 鹏程@CMBC 说: 2 | https://juejin.im/post/5cf5c817e51d454fbf5409b0 3 | 2019-06-04 18:39:54,244 khaozi@yrd 说: 4 | 现在星球搜索不方便了 5 | 2019-06-04 18:40:16,809 khaozi@yrd 说: 6 | 谁能帮忙发下之前 redis cluster关于分片的文章 7 | 2019-06-04 20:15:13,828 鹏程@CMBC 说: 8 | @khaozi@yrd 哪一篇？ 9 | 2019-06-04 20:22:02,083 khaozi@yrd 说: 10 | 讲集群自动分片的原理的 11 | 2019-06-04 21:15:31,148 张冬洪@CRUG 分享链接: 12 | 《内存数据库白皮书》重磅发布 13 | http://mp.weixin.qq.com/s?__biz=MjM5NjkxMjA1MA==&mid=2247484132&idx=1&sn=c762325bd3b76247d4928aacb2229dcd&chksm=a6e34c399194c52f0b7cbca5a62413939dfc642444dd0e72774d81a36fdc60f483e495945a0e&mpshare=1&scene=1&srcid=#rd 14 | 2019-06-04 22:06:39,940 黄靖凯@华为云 说: 15 | [强] 16 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-06.log: -------------------------------------------------------------------------------- 1 | 2019-06-06 01:03:07,310 xinxinbai@陌陌 说: 2 | 主从不一致，过期键的问题应该只有主库dump的时候才会发生 3 | 2019-06-06 01:04:31,485 xinxinbai@陌陌 说: 4 | 我记得 masterhost==null的时候，表示自己是主库。也就是说从库本来就不处理这套过期键的逻辑。 5 | 2019-06-06 01:05:07,323 xinxinbai@陌陌 说: 6 | 这也符合只读从库不会的数据库状态是完全由主库决定的这个逻辑 7 | 2019-06-06 01:14:34,588 xinxinbai@陌陌 说: 8 | 这也符合只读从库的数据库状态是完全由主库决定的，这个逻辑 9 | 2019-06-06 04:36:12,909 鹏程@CMBC 分享链接: 10 | #每日分享 「链接」 Counting Distinct Users in Real-Time With Redis Using Low Memory - DZone Database 11 | https://t.zsxq.com/jQvbaem 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-09.log: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/redisgroup.2019-06-09.log -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-10.log: -------------------------------------------------------------------------------- 1 | 2019-06-10 08:03:31,699 鹏程@CMBC 说: 2 | @焦清波@fh 发错了？ 3 | 2019-06-10 08:04:25,360 焦清波@fh 说: 4 | 发错了，抱歉 5 | 2019-06-10 08:12:43,854 鹏程@CMBC 分享链接: 6 | #每日分享 「链接」 你确定不来了解一下Redis列表的内部原理吗 - 掘金 7 | https://t.zsxq.com/7yRneI6 8 | 2019-06-10 16:50:40,143 白馨@陌陌 说: 9 | 有测试过碎片问题的，稳定复现碎片率高的测试吗？ 10 | 2019-06-10 23:52:28,558 小王@西安 说: 11 | 想问一下 12 | 13 | 新增节点，redis数据迁移过程中耗时较长，主要是因为单线程cpu到瓶颈，还是内存访问性能已到最大呢 14 | 有什么好的加速建议吗 15 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-11.log: -------------------------------------------------------------------------------- 1 | 2019-06-11 09:05:31,210 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redis专题(2)：Redis数据结构底层探秘 3 | https://t.zsxq.com/6m2vr7e 4 | 2019-06-11 10:45:17,395 chenssy@平安 说: 5 | 加入有 6379 6380 6381 三个主从节点，6379 为主节点，其余两个为从节点，但是后面 6379 挂了，6381 晋升为主机节点，请问6380 变成 6381 的从节点进行复制请求，第一次是全量复制还是部分复制 6 | 2019-06-11 10:45:20,516 chenssy@平安 说: 7 | 哪位大佬解释下 8 | 2019-06-11 10:45:25,264 chenssy@平安 说: 9 | [捂脸] 10 | 2019-06-11 10:47:20,067 Akkadian@神器 说: 11 | [抠鼻]不重启应该是部分复制吧，我也不懂 12 | 2019-06-11 10:47:43,340 黄威@国美 说: 13 | 后面版本不清楚，我们现在线上3.2.x版本的是全量复制 14 | 2019-06-11 10:48:22,679 chenssy@平安 说: 15 | 6380 请求的 runid 应该还是 6379 的runid ，我想是全量复制，但是我看日志是部分复制 16 | 2019-06-11 10:49:04,259 黄威@国美 说: 17 | 你们版本是？ 18 | 2019-06-11 10:49:10,328 黄建@友塔游戏 说: 19 | 4.0后的版本 了解一PSYNC 2.0 20 | 2019-06-11 10:49:19,060 chenssy@平安 说: 21 | 5 22 | 2019-06-11 10:51:16,576 陈宝仪@Redis-replicator 说: 23 | psyn2的话，避免了这个切换的全量复制 24 | 2019-06-11 10:55:16,436 chenssy@平安 说: 25 | 「 机器人小胖: 陈宝仪@Redis-replicator 说: 26 | psyn2的话，避免了这个切换的全量复制 」 27 | - - - - - - - - - - - - - - - 28 | 感谢指导，psyn2 我查下文章 29 | 2019-06-11 10:56:07,279 chenssy@平安 说: 30 | https://blog.csdn.net/n88Lpo/article/details/78529195 31 | 2019-06-11 10:56:31,535 chenssy@平安 说: 32 | 「 机器人小胖: 陈宝仪@Redis-replicator 说: 33 | psyn2的话，避免了这个切换的全量复制 」 34 | - - - - - - - - - - - - - - - 35 | 大佬，有文章推荐没？ 36 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-15.log: -------------------------------------------------------------------------------- 1 | 2019-06-15 12:34:09,951 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 如何使用Redis流和Apache Spark处理实时数据？ 3 | https://t.zsxq.com/fynmQZ7 4 | 2019-06-15 12:36:14,089 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 https://medium.com/swlh/task-scheduling-with-nodejs-and-redis-821461755891 6 | https://t.zsxq.com/unYFe6a 7 | 2019-06-15 19:45:56,047 鹏程@CMBC 说: 8 | @王珺@踢球者 无关话题 9 | 2019-06-15 19:49:07,689 王珺@踢球者 说: 10 | 不好意思碰到了。。。 11 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-16.log: -------------------------------------------------------------------------------- 1 | 2019-06-16 08:21:46,144 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Amazon ElastiCache launches reader endpoints for R... 3 | https://t.zsxq.com/62RnuZR 4 | 2019-06-16 11:19:02,550 Truman@newegg 说: 5 | Redis is compiled and linked against libc 6 | malloc by default, with the exception of jemalloc being the default on Linux 7 | systems. This default was picked because jemalloc has proven to have fewer 8 | fragmentation problems than libc malloc 9 | 2019-06-16 11:19:40,155 Truman@newegg 说: 10 | 这句话该怎么理解，redis 的默认分配器是jemalloc？ 11 | 2019-06-16 11:23:04,337 杨勇@cmb 说: 12 | 在有jemalloc时使用je，否则默认使用libc 13 | 2019-06-16 11:26:01,520 Truman@newegg 说: 14 | thanks 15 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-18.log: -------------------------------------------------------------------------------- 1 | 2019-06-18 01:43:13,837 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 https://medium.com/swlh/asynchronous-queueing-in-redis-with-akka-8b707b784bca 3 | https://t.zsxq.com/B2RZnUN 4 | 2019-06-18 04:20:13,852 赵梅@上海七牛云 说: 5 | 现在碰到个问题，redis4.0.7 ，观察日志是执行了删除请求，客户端没有报错，但是服务端缓存没被删除掉。现在排查是go语言客户端问题，还是服务端有问题。简单看了客户端代码，目前没有发现问题。大家有没有遇见过服务端出现这种问题的情况 6 | 2019-06-18 04:21:07,909 赵梅@上海七牛云 说: 7 | 收到删除请求，没有真正删除掉，而且没向客户端报错 8 | 2019-06-18 04:21:49,985 赵梅@上海七牛云 说: 9 | value也不大，几百个字节 10 | 2019-06-18 04:22:22,235 鹏程@CMBC 说: 11 | 中间有proxy什么的吗 12 | 2019-06-18 04:22:34,993 赵梅@上海七牛云 说: 13 | 删除后几个小时还能看见 14 | 2019-06-18 04:22:52,935 赵梅@上海七牛云 说: 15 | 没有，后面服务端是cluster 16 | 2019-06-18 04:25:23,474 赵梅@上海七牛云 说: 17 | string键，最简单的应用 18 | 2019-06-18 06:26:01,398 xinxinbai@陌陌 说: 19 | 客户端一般都是阻塞模式吧 发给redis请求 redis如果没有返回 最起码会报个超时 连超时都没有 只能说明没有发给redis 20 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-20.log: -------------------------------------------------------------------------------- 1 | 2019-06-20 00:49:08,096 黄威@国美 说: 2 | [强][强]，我个人觉得keydb更适合计算密集型的场景，数据库整体的性能都会在那把全局锁上。redis更偏向于io密集型场景，它的性能瓶颈在网卡上，要最大化提升网卡的性能，可以参考dpdk 3 | 2019-06-20 07:55:44,159 赵梅@上海七牛云 说: 4 | 昨天现象描述没错，原因定位错误，服务端会返回moved 127.0.0.1，不是因为bind的0.0.0.0关系，也不会因为要访问的redis是本机的另外一个端口，就返回127.0.0.1。因为重新新建集群，并没有复现这个问题。看到有问题的集群gossip msg传播了127.0.0.1，查历史记录运维操作扩容加入节点的时候竟然用了127.0.0.1的地址 5 | 2019-06-20 08:40:44,035 鹏程@CMBC 说: 6 | [嘿哈][嘿哈][机智] 7 | 2019-06-20 08:42:30,839 鹏程@CMBC 说: 8 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @曦馨 9 | 2019-06-20 08:44:23,043 曦馨 说: 10 | 好的 11 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-21.log: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/ChatRecords/redisgroup.2019-06-21.log -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-22.log: -------------------------------------------------------------------------------- 1 | 2019-06-22 03:05:56,315 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redis AI First Steps | Redis Labs 3 | https://t.zsxq.com/qv7AqFY 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-23.log: -------------------------------------------------------------------------------- 1 | 2019-06-23 15:15:40,545 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 解决Redis集群条件下键空间通知服务器接收不到消息的问题 - Mr.墨斗的博客 | MoDou B... 3 | https://t.zsxq.com/NrRB62V 4 | 2019-06-23 23:24:22,957 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 Redis 选择hash还是string 存储数据？ - 掘金 6 | https://t.zsxq.com/7mUrrJ6 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-25.log: -------------------------------------------------------------------------------- 1 | 2019-06-25 09:22:09,152 鹏程@CMBC 分享链接: 2 | 解读丨7分钟看懂华为云鲲鹏Redis背后的自研技术 3 | http://mp.weixin.qq.com/s?__biz=MzI1Mzc1MzMyOQ==&mid=2247498226&idx=1&sn=02dedfcb4869d820207bc9ac50f6bde6&chksm=e9cd1b6cdeba927a30d02e860f22c18c1e75f320e414c259b575f65b6e7f209b3dc1df7672a3&mpshare=1&scene=1&srcid=0625uYglKHJdSkwoGUfBzZit#rd 4 | 2019-06-25 09:22:38,572 鹏程@CMBC 说: 5 | @黄靖凯@华为云 还是没看明白华为云Redis产品的架构。。 6 | 2019-06-25 09:31:11,365 Rui Gu@Redisson 说: 7 | 给我的感觉OS上的改动才是最核心的东西 8 | 2019-06-25 10:22:17,751 黄威@国美 说: 9 | socket内核态切到用户态，可以参考dpdk 10 | 2019-06-25 10:22:23,361 鹏程@CMBC 说: 11 | 我也是这种感觉 说的那两个和Redis相关的架构图和没说没看出有什么特别大的差别…… @Rui Gu@Redisson 12 | 2019-06-25 10:23:01,956 黄威@国美 说: 13 | 腾讯有一个开源的实现fstack可以参考 14 | 2019-06-25 10:23:49,852 黄威@国美 说: 15 | 感觉就是dpdk 16 | 2019-06-25 10:24:49,957 黄威@国美 说: 17 | 应该是在链路上优化的比较多 18 | 2019-06-25 10:26:47,174 黄威@国美 说: 19 | https://github.com/cws06/fstack 20 | 2019-06-25 10:44:49,238 邓伟@jit 说: 21 | 分布式 libos也能共享一个进程？ 22 | 2019-06-25 10:48:39,395 黄威@国美 说: 23 | @白馨@陌陌 针对第四点，所以，华为推出的是arm架构的呀，arm省电 24 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-26.log: -------------------------------------------------------------------------------- 1 | 2019-06-26 07:14:50,376 唐唐@烽火 说: 2 | 请问一下， 3 | 在同等数据量，value大小相同，网络环境相同的情况下。 4 | codis槽位迁移快，还是redis Cluster槽位迁移快？ 5 | 6 | 有人测过吗？[害羞] 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-28.log: -------------------------------------------------------------------------------- 1 | 2019-06-28 03:03:27,414 雯岑@试金石信用 说: 2 | 想问下小伙伴们，为什么spop会让key不存在呢？ 3 | 2019-06-28 03:03:36,540 杨耀@必要科技 说: 4 | 集合空了吧 5 | 2019-06-28 03:03:38,134 雯岑@试金石信用 说: 6 | 集合空了会删除key？ 7 | 2019-06-28 03:04:12,849 雯岑@试金石信用 说: 8 | spop还会有这种操作吗？ 9 | 2019-06-28 03:25:12,002 柱星同学@pytc 说: 10 | @雯岑@试金石信用 11 | 2019-06-28 05:47:02,572 雯岑@试金石信用 说: 12 | 好的！谢谢@柱星同学@pytc  13 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-29.log: -------------------------------------------------------------------------------- 1 | 2019-06-29 04:01:25,450 鹏程@CMBC 说: 2 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @wenbc 3 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-06-30.log: -------------------------------------------------------------------------------- 1 | 2019-06-30 10:45:51,189 东风无眠@华泰证券 说: 2 | 求助个问题，redis迁移过程中遇到那种火星文的key，大家怎么解决的 3 | 2019-06-30 10:46:07,478 东风无眠@华泰证券 说: 4 | 这种没法通过脚本来写了。 5 | 2019-06-30 10:46:13,667 东风无眠@华泰证券 说: 6 | redis扩容 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-02.log: -------------------------------------------------------------------------------- 1 | 2019-07-02 03:07:58,516 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redigo源码分析 - Happen's Memo - SegmentFault 思否 3 | https://t.zsxq.com/b6qR3vb 4 | 2019-07-02 09:13:07,016 张晋涛@网易 说: 5 | 欢迎 @段 做下自我介绍 改个群名片 6 | 2019-07-02 09:16:12,813 段 说: 7 | 大家好，我是中银基金的段泽坤，请大家多多指教 8 | 2019-07-02 09:17:27,356 HQ@TAL 说: 9 | 幸好不是尖沙咀段坤 10 | 2019-07-02 09:17:52,743 段 说: 11 | 哈哈😄 12 | 2019-07-02 09:31:04,731 北极冷啊BG5FLH@yanji 说: 13 | 请问下 相同的数据量 Redis 用字符串存储和 HASH 表存储 哪个更节省内存 我看到资料是 存储相同量级的数据， Hash 结构消耗的内存只有字符串结构的 1/4 并查到 每种格式在redis内部都是两种存储格式 自动变换 请问这个结论是对的么 为什么hash 更节省内存？ 14 | 2019-07-02 10:05:19,294 鹏程@CMBC 说: 15 | 欢迎~ 16 | 2019-07-02 11:38:17,896 杨勇@cmb 说: 17 | 请教个问题，redis-cli --bigkeys会修改key的idletime，有办法规避不？ 18 | 2019-07-02 11:57:47,359 鹏程@CMBC 说: 19 | 木有... 20 | 2019-07-02 11:59:07,771 杨勇@cmb 说: 21 | 哈哈 22 | 2019-07-02 11:59:20,969 杨勇@cmb 说: 23 | 谢谢 24 | 2019-07-02 12:01:23,661 洋烊@借贷宝 说: 25 | @杨勇@cmb 如果idletime有特殊使用的话，你在从库上找big-key呗 26 | 2019-07-02 12:02:01,863 洋烊@借贷宝 说: 27 | 我还以为你用了贾乃亮的头像，点开一看发现不是 28 | 2019-07-02 12:04:40,748 Rui Gu@Redisson 说: 29 | 楼主说得好直接，一点幻想都不给人家留啊 30 | 2019-07-02 12:30:36,922 杭州-marvel@有赞 说: 31 | jedis 获取连接池经常失效，大家知道有什么原因么 32 | 2019-07-02 12:44:13,898 单汉强@网易游戏 说: 33 | @杨勇@cmb 拉个从出来扫？ 34 | 2019-07-02 12:47:33,292 单汉强@网易游戏 说: 35 | 噢，原来有人建议了，忽略 36 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-07.log: -------------------------------------------------------------------------------- 1 | 2019-07-07 14:50:33,706 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redis Clustering Best Practices with Keys | Redis ... 3 | https://t.zsxq.com/UNJq7Iy 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-08.log: -------------------------------------------------------------------------------- 1 | 2019-07-08 10:23:18,592 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redis 6采用新协议来实现客户端缓存功能 3 | https://t.zsxq.com/jeunuvN 4 | 2019-07-08 11:13:13,314 张冬洪@CRUG 分享链接: 5 | 数据未来！KV数据库最新前沿技术发展路径 6 | http://mp.weixin.qq.com/s?__biz=MjM5NjkxMjA1MA==&mid=2247484137&idx=1&sn=b899e4f460fce9e8dd069cacc07f16ba&chksm=a6e34c349194c5225d6d14e014b6902f302999adc18bf70370020e8828819b539707191a4ba9&mpshare=1&scene=1&srcid=#rd 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-10.log: -------------------------------------------------------------------------------- 1 | 2019-07-10 09:43:01,208 陈雷@滴滴 说: 2 | 这个封皮咋样 3 | 2019-07-10 09:43:12,296 鹏程@CMBC 说: 4 | 期待！ 5 | 2019-07-10 09:43:12,696 张冬洪@CRUG 说: 6 | [强] 7 | 2019-07-10 09:43:13,112 小易@易到 说: 8 | 牛皮 9 | 2019-07-10 09:43:13,512 强昌金@极数云舟 说: 10 | 棒 11 | 2019-07-10 09:43:13,916 Glenn@美团点评 说: 12 | [强] 13 | 2019-07-10 09:43:14,308 邓伟@jit 说: 14 | 「唐唐@烽火：请教一个问题。 15 | Redis get查询出现了大量的slowlog，设置大于5000微秒 16 | 17 | 确认 18 | 1.集群未开持久化 19 | 2.未开主从同步 20 | 3.查询过程未删除数据或增加数据，未进行rehash 21 | 22 | 还有什么情况会导致get命令处理耗时变高？」 23 | - - - - - - - - - - - - - - - 24 | 排查出问题了吗？ 25 | 2019-07-10 09:43:14,694 李文@长兴 说: 26 | [强] 27 | 2019-07-10 09:52:02,374 张晋涛@网易 说: 28 | [强] 期待！ 29 | 2019-07-10 09:53:53,551 tiger@欢乐逛 说: 30 | [强] 31 | 2019-07-10 09:54:39,687 王江华@好未来 说: 32 | [强]期待！ 33 | 2019-07-10 09:55:38,369 秦亚男@lagou 说: 34 | [强]期待！ 35 | 2019-07-10 09:56:08,011 andy@BBD 说: 36 | 期待 37 | 2019-07-10 09:57:16,555 鹏程@CMBC 说: 38 | 剧透下，不夸张的说，个人觉得如果你喜欢前几年黄健宏写的那本Redis设计与实现，那这本书你会彻底爱上。 39 | 2019-07-10 09:58:17,096 周阳@国美 说: 40 | 那这个真的来一本 41 | 2019-07-10 09:59:07,382 波罗@中国PG分会 说: 42 | [强] 43 | 2019-07-10 09:59:07,692 张晋涛@网易 说: 44 | 是不是近期就能上市了 45 | 2019-07-10 09:59:13,687 陈宝仪@Redis-replicator 说: 46 | [强] 47 | 2019-07-10 10:06:02,486 wettper@微博 说: 48 | [强]期待！ 49 | 2019-07-10 10:15:48,849 焦清波@fh 说: 50 | 搞个团购，有优惠吗 51 | 2019-07-10 10:16:59,497 吴建超@youku 说: 52 | @陈雷@滴滴 [强] 53 | 2019-07-10 10:18:02,483 邓伟@jit 说: 54 | 买个皮 55 | 2019-07-10 10:18:28,362 goddie@汇量科技 说: 56 | [强] 57 | 2019-07-10 10:28:50,423 singgel@雪球 说: 58 | [强] 59 | 2019-07-10 11:11:15,542 唐唐@烽火 说: 60 | @邓伟@jit 还没呢，今天还没来的及看呢。 61 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-11.log: -------------------------------------------------------------------------------- 1 | 2019-07-11 01:18:03,144 零度@changtu 分享链接: 2 | 关于Redis存在远程命令执行漏洞的安全公告 3 | http://mp.weixin.qq.com/s?__biz=MzU2NjIzNDk5NQ==&mid=2247486940&idx=1&sn=b4edc308952645621a266913ff2275ff&chksm=fcaed7c0cbd95ed6648b978c9bde786aef89bdd665d6eb21bb59d9b65b8fb65082eb5c018c7e&mpshare=1&scene=1&srcid=#rd 4 | 2019-07-11 02:53:59,229 arthur@baidu 说: 5 | 作者2天前已经修复了 https://github.com/antirez/redis/issues/6214 6 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-12.log: -------------------------------------------------------------------------------- 1 | 2019-07-12 06:42:46,179 刘宝珍 说: 2 | 问个问题， python支持连接池连接sentinel的集群吗？ 3 | 2019-07-12 07:57:28,616 张晋涛@网易 说: 4 | 可以 5 | 2019-07-12 07:58:03,442 刘宝珍 说: 6 | 支持sentinel，我知道。没看到支持用sentinel的连接池啊 7 | 2019-07-12 07:58:27,285 刘宝珍 说: 8 | 哪个lib库。 @张晋涛@网易 9 | 2019-07-12 08:02:01,001 鹏程@CMBC 说: 10 | https://github.com/andymccurdy/redis-py 11 | 2019-07-12 08:02:14,172 鹏程@CMBC 说: 12 | redis-py can be used together with Redis Sentinel to discover Redis nodes. 13 | 2019-07-12 08:02:46,092 鹏程@CMBC 说: 14 | 连接池应该没有 15 | 2019-07-12 08:03:00,964 鹏程@CMBC 说: 16 | py自己搞了估计得 17 | 2019-07-12 08:03:41,431 张晋涛@网易 说: 18 | 这个也能搞得 19 | 2019-07-12 08:04:05,989 鹏程@CMBC 说: 20 | 看了眼可以 21 | 2019-07-12 08:04:07,596 鹏程@CMBC 说: 22 | 是的 23 | 2019-07-12 08:04:17,314 鹏程@CMBC 说: 24 | class SentinelConnectionPool(ConnectionPool): 25 | 2019-07-12 08:10:26,794 刘宝珍 说: 26 | master切换的时候，连接池可以感知吗？ 27 | 2019-07-12 08:13:56,015 刘宝珍 说: 28 | 我没看到啊，这个不是sentinel创建的连接池啊 29 | 2019-07-12 09:21:45,676 单汉强@网易游戏 说: 30 | 可以感知 31 | 2019-07-12 10:18:05,894 刘宝珍 说: 32 | ok，谢了。 33 | 2019-07-12 10:26:50,911 鹏程@CMBC 说: 34 | @刘宝珍 亲，改个群名片~ 35 | 2019-07-12 10:29:12,841 刘宝珍 说: 36 | ok，已改 37 | 2019-07-12 10:32:53,828 鹏程@CMBC 说: 38 | 这....亲看下群公告，谢谢 39 | 2019-07-12 10:32:57,390 鹏程@CMBC 说: 40 | @改个群名片 41 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-13.log: -------------------------------------------------------------------------------- 1 | 2019-07-13 11:08:03,580 曾庆勇@盖娅 说: 2 | 遇到个问题，麻烦大佬看看给个思路怎么查 3 | 我们这边用PHP写入到redis 4.0，写入的时候，返回是成功，然后上redis去查，却没有值 4 | 概率大概有2%到3% 5 | 2019-07-13 11:13:42,382 武文齐@CMBC 说: 6 | 看看php返回的结果确认是redis返回的直接结果吗，有没有中间做转换？ 7 | 2019-07-13 11:23:07,083 曾庆勇@盖娅 说: 8 | 没有，现在程序是直接用的模块，本身没有做验证，以前一直这么用，返回成功就认为成功了 9 | 2019-07-13 11:27:17,036 曾庆勇@盖娅 说: 10 | php-redis，返回就是1，写入成功 11 | 2019-07-13 11:33:01,975 武文齐@CMBC 说: 12 | 把有问题的key单拿出来，看看是否能复现，然后抓个包？ 13 | 2019-07-13 11:39:41,865 黄建@友塔游戏 说: 14 | 开monitor 确认一下 redis执行记录 或者查一下aof？ 有没可能执行成功但被删除了 或者哪里设置过期 15 | 2019-07-13 11:41:21,740 曾庆勇@盖娅 说: 16 | 动静都比较大，还有别的什么思路吗？ 17 | 2019-07-13 11:43:41,124 黄建@友塔游戏 说: 18 | Slave上查呗 19 | 2019-07-13 11:48:12,886 曾庆勇@盖娅 说: 20 | slave上也没有啊 21 | 2019-07-13 11:48:19,308 曾庆勇@盖娅 说: 22 | 主上查都没有 23 | 2019-07-13 11:49:26,605 黄建@友塔游戏 说: 24 | 查过程 25 | 2019-07-13 11:50:12,437 黄建@友塔游戏 说: 26 | 逻辑是先查redis收到没有，再查是不是删掉或者过期 27 | 2019-07-13 12:04:38,998 邓伟@jit 说: 28 | 查也要查根本，因为现象这样做，不行的 29 | 2019-07-13 12:13:11,544 单汉强@网易游戏 说: 30 | 整个场景再详细描述一下，还有怎么复现，具体什么类型的key等信息 31 | 2019-07-13 13:29:32,952 邓伟@jit 说: 32 | 必要时可以贴图 33 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-15.log: -------------------------------------------------------------------------------- 1 | 2019-07-15 01:43:47,183 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 关于Redis热点key的一些思考 - 个人文章 - SegmentFault 思否 3 | https://t.zsxq.com/NBQJeaq 4 | 2019-07-15 02:13:47,531 京东到家-殷帅 说: 5 | redis主从同步是怎么同步的，他的文件格式是什么 6 | 2019-07-15 02:26:31,981 鹏程@CMBC 说: 7 | 这个翻下群分享或Google应该很多吧，不知道具体你要了解什么 8 | 2019-07-15 07:56:32,561 曾庆勇@盖娅 说: 9 | 查到了原因，和redis无关，我们使用的一个随机函数，在一个特殊情况下产生了重复结果，我们的业务逻辑是如果重复了会顶掉之前的值，所以查不到 10 | 2019-07-15 07:58:10,325 肖贝贝@BIGO 说: 11 | 好棒, 问了问题自己查到原因说出来是个好习惯[呲牙], 咋查到的, 看的aof记录吗 12 | 2019-07-15 07:59:10,084 张玉川@天脉 说: 13 | 估计是业务分析出来的 14 | 2019-07-15 08:03:13,997 曾庆勇@盖娅 说: 15 | 是看的aof记录 16 | 2019-07-15 08:03:33,765 曾庆勇@盖娅 说: 17 | 纯看业务那边实际看不出来，业务逻辑没问题，代码逻辑没问题，就出在一个随机函数上 18 | 2019-07-15 08:05:22,109 鹏程@CMBC 说: 19 | [强][强]有反馈的好同志~ 20 | 2019-07-15 08:05:58,633 张玉川@天脉 说: 21 | [强]这种错误一般不会出现在底层的软件上，大部分都是业务的逻辑处理错误，而且还不容易被发现 22 | 2019-07-15 08:17:58,444 曾庆勇@盖娅 说: 23 | 是的 24 | 2019-07-15 08:34:10,053 黄建@友塔游戏 说: 25 | 😂 aof最直接 26 | 2019-07-15 23:22:00,700 鹏程@CMBC 分享链接: 27 | #每日分享 「链接」 怎样做可靠的分布式锁，Redlock 真的可行么？ 28 | https://t.zsxq.com/nQ3RNBA 29 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-16.log: -------------------------------------------------------------------------------- 1 | 2019-07-16 00:44:38,732 Jacob@网易 说: 2 | @机器人小胖 微信聊天机器人，是怎么实现的？有好的开源吗？ 3 | 2019-07-16 00:49:10,748 鹏程@CMBC 说: 4 | @Jacob@网易 麻烦不要圈它，请看群公告，谢谢 5 | 2019-07-16 00:52:02,093 Jacob@网易 说: 6 | 多谢，不好意思没细看公告 7 | 2019-07-16 00:54:20,031 鹏程@CMBC 说: 8 | 没事，在群公告第一条 9 | 2019-07-16 23:58:30,990 鹏程@CMBC 分享链接: 10 | #每日分享 「链接」 GitHub - fetlife/redis-analyzer: Redis Memory Anal... 11 | https://t.zsxq.com/QFiieeI 12 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-21.log: -------------------------------------------------------------------------------- 1 | 2019-07-21 08:12:24,498 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 浅析Redis中SSRF的利用 3 | https://t.zsxq.com/zzZzvnu 4 | 2019-07-21 15:55:09,294 李文@长兴 说: 5 | [强] 6 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-22.log: -------------------------------------------------------------------------------- 1 | 2019-07-22 16:40:04,401 鹏程@CMBC 说: 2 | 推荐这一篇。 3 | 2019-07-22 16:40:07,100 鹏程@CMBC 分享链接: 4 | #每日分享 「链接」 Prometheus实战：关于Redis序列化及压缩对性能的影响 5 | https://t.zsxq.com/rVnUrZj 6 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-24.log: -------------------------------------------------------------------------------- 1 | 2019-07-24 09:54:12,538 鹏程@CMBC 分享链接: 2 | 第10期预告：Redis 应用与优化最佳实践--八里庄技术沙龙 3 | http://mp.weixin.qq.com/s?__biz=Mzg2NzEwMjEwMQ==&mid=2247483922&idx=1&sn=6407712da5360167c6063b6e98b2c02f&chksm=ce41fee8f93677feb71ef330515fbc28bd13b65102f854e55bb4a805aea245c836db242a9782&mpshare=1&scene=1&srcid=0723UwyoecBsftIdAb3a3lcF&sharer_sharetime=1563884648254&sharer_shareid=c6956170fd4fb4420832b556d7c1fdc5#rd 4 | 2019-07-24 09:55:13,681 鹏程@CMBC 说: 5 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @吃你家棒子面啦？！ 6 | 2019-07-24 10:08:08,197 鹏程@CMBC 分享链接: 7 | #每日分享 「链接」 新东方的Kubernetes实践：从服务化ES到Kafka和Redis 8 | https://t.zsxq.com/qVFIaA2 9 | 2019-07-24 10:12:12,157 鹏程@CMBC 说: 10 | @所有人 麻烦问大家一下有人能联系上新东方的这两位工程师吗？ 11 | 12 | 姜江，新东方信息管理部平台架构负责人 13 | 14 | 陈博暄，新东方信息管理部高级运维工程师 15 | 2019-07-24 10:12:46,956 鹏程@CMBC 说: 16 | @所有人 麻烦问大家一下有人能联系上新东方的这两位工程师吗？ 17 | 18 | 姜江，新东方信息管理部平台架构负责人 19 | 20 | 陈博暄，新东方信息管理部高级运维工程师 21 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-25.log: -------------------------------------------------------------------------------- 1 | 2019-07-25 18:24:12,371 姜正中@CMBC 说: 2 | 大家有没有用cachecloud管理redis的 关于短信报警这块儿配置是怎样的呢 3 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-26.log: -------------------------------------------------------------------------------- 1 | 2019-07-26 11:36:54,468 幻想 说: 2 | 请问大家有没有遇到过redis cluster在添加节点与删除节点时，用HyperLogLog进行排重，对500不同的val进行排重，最后的结果是503，这样正常吗？不太理解 3 | 2019-07-26 11:44:52,527 gukf@牛栏 说: 4 | 这个本来就是不精确的 5 | 2019-07-26 11:45:56,101 幻想 说: 6 | 但是500个val排重变为503，也正常吗 7 | 2019-07-26 14:21:50,516 鹏程@CMBC 说: 8 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @贾杰@newsdog 9 | 2019-07-26 14:26:57,375 贾杰@newsdog 说: 10 | 大家好，多谢@鹏程@CMBC 。我叫贾杰目前在newsdog负责大数据，运维相关工作。向大家学习，多多交流。 11 | 2019-07-26 15:05:17,093 鹏程@CMBC 说: 12 | 欢迎~ 13 | 2019-07-26 15:05:34,650 鹏程@CMBC 说: 14 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @冬菇先生 15 | 2019-07-26 15:06:12,305 东风无眠@华泰证券 说: 16 | @鹏程@CMBC 我邀请的，你两改下名字😄 17 | 2019-07-26 15:17:00,323 鹏程@CMBC 说: 18 | 嗯，欢迎~也是华泰的同事？ 19 | 2019-07-26 15:17:25,055 冬菇先生@华泰证券 说: 20 | 是的 21 | 2019-07-26 15:19:03,274 鹏程@CMBC 说: 22 | 欢迎~ 23 | 2019-07-26 15:19:18,594 冬菇先生@华泰证券 说: 24 | [抱拳] 25 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-27.log: -------------------------------------------------------------------------------- 1 | 2019-07-27 08:34:56,760 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 5 Steps to Building a Great Redis Module | Redis Labs 3 | https://t.zsxq.com/623faUn 4 | 2019-07-27 10:12:36,634 单汉强@网易游戏 分享链接: 5 | 从清档需求谈谈 Redis 二级索引的使用 6 | http://mp.weixin.qq.com/s?__biz=MzAwNjk0OTk0Mw==&mid=2247483704&idx=1&sn=1f9021d0b1a45e597385e1d912b56b4e&chksm=9b04dc60ac735576320829884a345e5d09b9a824ab840b3a74c3aba26805b8624ad9f736e968&mpshare=1&scene=1&srcid=0727e7IJ8rXaE9xjN7enWatd&sharer_sharetime=1564193627705&sharer_shareid=9868cf3e8c37ce3f1a7fcf6872cb39bf#rd 7 | 2019-07-27 10:13:17,933 单汉强@网易游戏 说: 8 | 分享一些Redis使用的日常 9 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-29.log: -------------------------------------------------------------------------------- 1 | 2019-07-29 17:07:22,124 黄威@国美 说: 2 | [强] 3 | 2019-07-29 17:07:34,239 Glenn@美团点评 说: 4 | [强] 5 | 2019-07-29 17:07:46,264 大鹏@神州优车 说: 6 | [强] 7 | 2019-07-29 17:08:03,221 波罗@中国PG分会 说: 8 | [强] 9 | 2019-07-29 18:02:23,087 赖晓航@4399 说: 10 | [强] 11 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-30.log: -------------------------------------------------------------------------------- 1 | 2019-07-30 06:36:12,599 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Redis大key多key拆分方案 3 | https://t.zsxq.com/qZnqFiu 4 | 2019-07-30 10:21:46,150 Mr_杨@便利蜂 说: 5 | 内容被删除了 6 | 2019-07-30 11:49:29,120 张晋涛@网易 说: 7 | https://gist.github.com/antirez/7e2a4b7a17907a765ab40c7e2dc11d23 Redis OOS mode 8 | 2019-07-30 11:52:53,148 麦霍键@腾讯 说: 9 | 请问下，通过php写数据到redis，有压缩的设置吗？目前数据量比较大，想在写入前先做压缩，减少内存的消耗 10 | 2019-07-30 11:55:08,201 肖贝贝@BIGO 说: 11 | 通用的数据压缩似乎不支持, 不过可以通过更换数据结构在某些场景下获得比较好的内存节省 12 | 2019-07-30 11:56:08,912 小明-魔都-TrustAsia 说: 13 | 要是我，宁愿拆应用，多启几个实例算了 14 | 2019-07-30 11:57:29,565 RoderickYu@微爱 说: 15 | 让redis做压缩是不是不太好。在业务层压缩完存进去，取的时候也是在业务层解压一下。。 16 | 2019-07-30 11:58:47,080 鹏程@CMBC 说: 17 | 看场景了，如果latency满足而内存是大的问题，那这么优化当然也没问题 18 | 2019-07-30 12:00:28,553 鹏程@CMBC 分享链接: 19 | #每日分享 「链接」 Prometheus实战：关于Redis序列化及压缩对性能的影响 20 | https://t.zsxq.com/rVnUrZj 21 | 2019-07-30 12:00:38,841 鹏程@CMBC 说: 22 | @麦霍键@腾讯 你看看？ 23 | 2019-07-30 12:01:03,570 鹏程@CMBC 说: 24 | 不过php就不懂了是不是有对应的序列化方法 25 | 2019-07-30 12:02:54,378 麦霍键@腾讯 说: 26 | 就是需要在写入到redis前先做压缩，需要php的扩展支持，不知道这块有没有经验的朋友实践过 27 | 2019-07-30 12:17:09,216 麦霍键@腾讯 说: 28 | 放内存里，latency应该是很低的，主要是减少内存的容量，因为内存贵哇 29 | 2019-07-30 12:20:17,248 麦霍键@腾讯 说: 30 | @鹏程@CMBC 这个文章不错，我再找找看php有这个扩展不 31 | 2019-07-30 12:22:14,319 单汉强@网易游戏 说: 32 | @张晋涛@网易 33 | https://gist.github.com/antirez/7e2a4b7a17907a765ab40c7e2dc11d23 Redis OOS mode 34 | 35 | 这个可以有啊，我们现在就是搞的主关掉持久化，只在从节点上开持久化。之前还想着能不能把这个搞成一个redis 的 feature，看来作者已经想到了 36 | 2019-07-30 12:34:16,323 鹏程@CMBC 说: 37 | @张晋涛@网易 群众的呼声 38 | 2019-07-30 12:52:57,708 张晋涛@网易 说: 39 | 😄 40 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-07-31.log: -------------------------------------------------------------------------------- 1 | 2019-07-31 09:44:53,257 东风无眠@华泰证券 说: 2 | 问下大家，谁知道redis5里面cluster模式增量复制完全好用了吗？ 3 | 2019-07-31 14:26:31,582 cici®@小猪科技 说: 4 | 你们的 Redis 版本都用那么新的嘛？ 5 | 2019-07-31 14:33:16,690 怒力@高晟京 说: 6 | 必须 7 | 2019-07-31 15:02:45,821 鹏程@CMBC 说: 8 | 欢迎新来的朋友~方便做个简单自我介绍，再把群名片改下名字@公司~然后看下群公告，谢谢！ @海中王. 9 | 2019-07-31 20:22:30,562 白馨@陌陌 说: 10 | 请问各位大佬 Redis cluster 的可用性 当两个节点故障时 1-(1/(N*2-1))的可能性不可用 这是根据什么算的 11 | 2019-07-31 20:31:00,343 单汉强@网易游戏 说: 12 | 这个可能性是指同一个分片的主从都挂掉的情况 13 | 2019-07-31 20:31:23,463 白馨@陌陌 说: 14 | 我知道 15 | 2019-07-31 20:31:26,085 白馨@陌陌 说: 16 | 我是说公职 17 | 2019-07-31 20:31:29,293 白馨@陌陌 说: 18 | 公式 19 | 2019-07-31 20:32:07,027 白馨@陌陌 说: 20 | 1-(1/(N*2-1)) 我现在1-10都数不清[捂脸] 数学不能理解 21 | 2019-07-31 20:32:35,363 单汉强@网易游戏 说: 22 | N个一主一从的分片，挂掉一个，剩下2N-1个节点，再挂该分片的的另一个节点的概率，就是1 / (2N-1) 23 | 2019-07-31 20:33:03,926 单汉强@网易游戏 说: 24 | N个一主一从的分片，总共2N个节点，挂掉一个节点，剩下2N-1个节点，再挂该分片的的另一个节点的概率，就是1 / (2N-1) 25 | 2019-07-31 20:33:33,914 单汉强@网易游戏 说: 26 | 可用性就是 1 - 1/(2N-1) 27 | 2019-07-31 20:37:55,580 单汉强@网易游戏 说: 28 | 这里说的可用性，完整的背景，我没有记错应该是，当一个集群挂了一个节点，再挂一个节点时，整个集群仍然是可用的，这个事件的概率是1 - 1/(2N-1)。 29 | 2019-07-31 20:38:41,415 白馨@陌陌 说: 30 | 嗯嗯 [强] 31 | 2019-07-31 20:45:38,168 张仕华@滴滴 说: 32 | [强] 33 | 2019-07-31 21:00:12,291 张贵川@mz 说: 34 | [强][强]赞 35 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-03.log: -------------------------------------------------------------------------------- 1 | 2019-08-03 20:27:37,821 单汉强@网易游戏 说: 2 | 发现目前很少关于Redis6的文章，于是参考作者在redis day的redis6的分享整理了一篇。有兴趣可以看看，欢迎交流[憨笑] 3 | 2019-08-03 20:27:48,217 单汉强@网易游戏 分享链接: 4 | Redis 6 新功能提前看 5 | http://mp.weixin.qq.com/s?__biz=MzAwNjk0OTk0Mw==&mid=2247483726&idx=1&sn=476ca8efa410d35b1f9cebcce9c766fe&chksm=9b04dc16ac73550011d94e2030e4cdfe152fa7da3cfb2a47a940c493631acfc2e09e1e6af90d&mpshare=1&scene=1&srcid=&sharer_sharetime=1564835239858&sharer_shareid=9868cf3e8c37ce3f1a7fcf6872cb39bf#rd 6 | 2019-08-03 21:10:27,947 张皓_小作坊棋牌 说: 7 | 666 8 | 2019-08-03 21:10:28,249 张皓_小作坊棋牌 说: 9 | 期待proxy 10 | 2019-08-03 21:47:38,550 鹏程@CMBC 说: 11 | [机智][机智][机智][机智] 12 | 2019-08-03 22:03:18,545 鹏程@CMBC 说: 13 | https://youtu.be/lo-Pgf_l7_M 14 | 2019-08-03 22:03:29,856 鹏程@CMBC 说: 15 | @单汉强@网易游戏 文章的对应视频 16 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-05.log: -------------------------------------------------------------------------------- 1 | 2019-08-05 08:04:19,657 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 老年代又占用100%了，顺便发现了vertx-redis-client 的bug 3 | https://t.zsxq.com/fEeaEyB 4 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-08.log: -------------------------------------------------------------------------------- 1 | 2019-08-08 16:05:06,448 Rui Gu@Redisson 说: 2 | 潜水的都出来了…… 3 | 2019-08-08 16:05:28,282 刘金勇@光宇游戏 说: 4 | [鼓掌] 5 | 2019-08-08 16:09:28,706 曲勇@51talk 说: 6 | 谢老板 7 | 2019-08-08 16:09:55,617 Rui Gu@Redisson 说: 8 | 求大家转发朋友圈。谢谢。 9 | 2019-08-08 16:10:05,514 田斌@京东 说: 10 | 红包没有同步过来，哈哈 11 | 2019-08-08 16:11:05,666 Rui Gu@Redisson 说: 12 | 楼主手动同步一下吧[偷笑][偷笑][偷笑] 13 | 2019-08-08 16:14:32,243 Truman@newegg 说: 14 | [机智] 15 | 2019-08-08 16:15:23,946 HQ@TAL 说: 16 | 红包手动同步 17 | 2019-08-08 17:06:46,605 Rui Gu@Redisson 说: 18 | 感谢大家的支持！ 19 | 2019-08-08 17:07:20,840 Rui Gu@Redisson 说: 20 | 希望大家能够在朋友圈里传播一下我们项目，谢谢大家 21 | 2019-08-08 17:11:23,744 鹏程@CMBC 说: 22 | @Rui Gu@Redisson 来个地址方便转~ 23 | 2019-08-08 17:12:05,495 鹏程@CMBC 分享链接: 24 | https://github.com/redisson/redisson 25 | 26 | 2019-08-08 17:17:59,872 Rui Gu@Redisson 说: 27 | 感谢楼主发传送门 28 | 2019-08-08 17:21:29,561 子嘉@阿里云 说: 29 | @Rui Gu@Redisson 祝贺 30 | 2019-08-08 17:22:04,267 Rui Gu@Redisson 说: 31 | @子嘉@阿里云 感谢子嘉的关心 32 | 2019-08-08 17:23:42,442 张立志@失业中 说: 33 | 给顾老师分享一波 34 | 2019-08-08 17:24:49,712 Rui Gu@Redisson 说: 35 | @ 张立志@失业中 感谢感谢 36 | 2019-08-08 18:01:49,127 星星@游戏 说: 37 | 主要是红包没同步过来 38 | 2019-08-08 18:10:57,474 Rui Gu@Redisson 说: 39 | 哎，这个功能还需要跟楼主提[偷笑] 40 | 2019-08-08 18:11:54,426 星星@游戏 说: 41 | 😂 这机器人好智能，这都识别出来了 42 | 2019-08-08 19:06:06,936 白馨@陌陌 说: 43 | @黄威@国美 其实我更关心有没有人遇到上述情况 就是大量半连接的情况😁 44 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-19.log: -------------------------------------------------------------------------------- 1 | 2019-08-19 08:34:27,736 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 七问Redis，才知道我与技术大牛的差距在哪里 3 | https://t.zsxq.com/n6yRvVB 4 | 2019-08-19 08:34:39,805 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 七问Redis，才知道我与技术大牛的差距在哪里 6 | https://t.zsxq.com/n6yRvVB 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-23.log: -------------------------------------------------------------------------------- 1 | 2019-08-23 23:38:00,976 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 【Redis】滑动窗口实现访问频率控制 3 | https://t.zsxq.com/6mU3BMB 4 | 2019-08-23 23:38:12,568 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 【Redis】滑动窗口实现访问频率控制 6 | https://t.zsxq.com/6mU3BMB 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-25.log: -------------------------------------------------------------------------------- 1 | 2019-08-25 10:04:51,322 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 当面试遇到 Redis，我作为一个面试官是这么“刁难”你的！ 3 | https://t.zsxq.com/ZFuR76y 4 | 2019-08-25 10:05:01,580 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 当面试遇到 Redis，我作为一个面试官是这么“刁难”你的！ 6 | https://t.zsxq.com/ZFuR76y 7 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-27.log: -------------------------------------------------------------------------------- 1 | 2019-08-27 17:41:00,162 杨勇@cmb 说: 2 | [鼓掌] 3 | 2019-08-27 17:41:10,929 杨勇@cmb 说: 4 | [鼓掌] 5 | 2019-08-27 22:21:09,238 鹏程@CMBC 分享链接: 6 | #每日分享 「链接」 一个简单的基于 Redis 的分布式任务调度器 —— Java 语言实现 7 | https://t.zsxq.com/eYZ3R33 8 | 2019-08-27 22:21:09,547 鹏程@CMBC 分享链接: 9 | #每日分享 「链接」 一个简单的基于 Redis 的分布式任务调度器 —— Java 语言实现 10 | https://t.zsxq.com/eYZ3R33 11 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-08-28.log: -------------------------------------------------------------------------------- 1 | 2019-08-28 09:02:20,321 何铁头@wl 说: 2 | 请问可有哪位大佬遇到过机房网络波动(人为触碰造成)，引起redis-cluster的切换故障 3 | 2019-08-28 09:02:32,254 何铁头@wl 说: 4 | 请问可有哪位大佬遇到过机房网络波动(人为触碰造成)，引起redis-cluster的切换故障 5 | 2019-08-28 09:02:50,991 何铁头@wl 说: 6 | 类似这样的情况 7 | 2019-08-28 09:02:51,302 何铁头@wl 说: 8 | 类似这样的情况 9 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-09-03.log: -------------------------------------------------------------------------------- 1 | 2019-09-03 21:43:28,606 鹏程@CMBC 说: 2 | @谢岳生@一智通 欢迎~ 3 | 2019-09-03 21:43:59,894 鹏程@CMBC 说: 4 | @张晋涛@网易 是的，时间过的真快 5 | 2019-09-03 21:44:59,174 谢岳生@一智通 说: 6 | @鹏程@CMBC 谢谢，你跟我一个朋友名字一样😄 7 | 2019-09-03 21:45:15,058 鹏程@CMBC 说: 8 | 哈哈，缘分~ 9 | 2019-09-03 21:47:11,319 鹏程 说: 10 | 我debug看下 11 | 2019-09-03 21:47:11,651 鹏程 说: 12 | 我debug看下 13 | 2019-09-03 21:49:15,884 鹏程 说: 14 | 测试三群 15 | 2019-09-03 21:49:16,194 鹏程 说: 16 | 测试三群 17 | 2019-09-03 21:51:12,356 鹏程@CMBC 说: 18 | 目前两个群都基本上满了哈，要是有新朋友加进来，可以让他先加我或者@张晋涛@网易有道 @孔唯妍-soul 19 | 2019-09-03 21:51:17,166 鹏程@CMBC 说: 20 | 目前两个群都基本上满了哈，要是有新朋友加进来，可以让他先加我或者@张晋涛@网易有道 @孔唯妍-soul 21 | 2019-09-03 21:52:29,437 海涛@SPDB 说: 22 | 群主这个机器人代码开源了吗 23 | 2019-09-03 21:52:29,712 海涛@SPDB 说: 24 | 群主这个机器人代码开源了吗 25 | 2019-09-03 21:52:31,352 海涛@SPDB 说: 26 | 我想用一下 27 | 2019-09-03 21:52:31,664 海涛@SPDB 说: 28 | 我想用一下 29 | 2019-09-03 21:56:19,025 鹏程 分享链接: 30 | #每日分享 「链接」 Redis 混合存储最佳实践指南 31 | https://t.zsxq.com/YjMv7AE 32 | 2019-09-03 21:56:19,337 鹏程 分享链接: 33 | #每日分享 「链接」 Redis 混合存储最佳实践指南 34 | https://t.zsxq.com/YjMv7AE 35 | 2019-09-03 21:56:47,204 鹏程@CMBC 说: 36 | @海涛@SPDB 看群公告哈 37 | 2019-09-03 21:56:47,558 鹏程@CMBC 说: 38 | @海涛@SPDB 看群公告哈 39 | 2019-09-03 21:57:24,380 海涛@SPDB 说: 40 | 谢谢 41 | 2019-09-03 21:57:25,320 海涛@SPDB 说: 42 | 谢谢 43 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-09-07.log: -------------------------------------------------------------------------------- 1 | 2019-09-07 22:51:06,515 NiZerin 说: 2 | 希望能和各位大佬探讨交流 redis 技术 3 | 2019-09-07 22:51:11,839 NiZerin 说: 4 | [呲牙] 5 | 2019-09-07 22:51:23,550 鹏程@CMBC 说: 6 | @NiZerin 欢迎，改个群名片~ 7 | 2019-09-07 22:51:55,728 NiZerin 说: 8 | ok 9 | 2019-09-07 22:53:34,130 鹏程@CMBC 分享链接: 10 | #每日分享 「链接」 广告点击数实时统计：Spark StructuredStreaming + Redis Stream... 11 | https://t.zsxq.com/ieQfMfU 12 | 2019-09-07 23:01:19,967 鹏程@CMBC 说: 13 | @所有人 由于群满员，近期将对尚未根据群规更改群名片的成员进行清理，如有误伤请随时加我微信，谢谢~ 14 | 2019-09-07 23:02:00,545 Rocky@华征 说: 15 | [强] 16 | 2019-09-07 23:17:15,092 Mr.Dragon@Cxy 说: 17 | [OK] 18 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-09-08.log: -------------------------------------------------------------------------------- 1 | 2019-09-08 08:02:53,537 姚吉祥@金智软件 说: 2 | [强] 3 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-10-11.log: -------------------------------------------------------------------------------- 1 | 2019-10-11 04:12:46,728 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 A Multithreaded Fork of Redis That’s 5X Faster Tha... 3 | https://t.zsxq.com/BiEaAii 4 | 2019-10-11 04:38:04,775 秦红胜@EmbraceSource 说: 5 | 国内有人用这个多线程的Redis分支 KeyDB 6 | 2019-10-11 04:38:08,078 秦红胜@EmbraceSource 说: 7 | 吗 8 | 2019-10-11 04:41:09,166 刘文举@北京默契破冰科技有限公司 说: 9 | 「 张立志@失业中: 各位 redis set ismember为什么是o1 」 10 | - - - - - - - - - - - - - - - 11 | set使用value=null的hash实现的，判断是否存在就是o1的了。 12 | 2019-10-11 14:39:42,092 Glenn@美团点评 说: 13 | mysql快了 14 | 2019-10-11 14:45:18,289 张立志@失业中 说: 15 | @刘文举@北京默契破冰科技有限公司 这是在hash 的情况下，这种情况不用讨论，理想情况下，没有冲突就是o1 16 | 2019-10-11 14:45:38,025 张立志@失业中 说: 17 | 但在intset 情况下，则不然 18 | 2019-10-11 14:46:19,269 张立志@失业中 说: 19 | intsetSearch 查找给定的整数是否在intset中 O(logN) 20 | intsetUpgradeAndAdd 先升级intset然后插入元素 O(N) 21 | intsetAdd 直接添加元素 O(N) 22 | intsetMoveTail 将intset中元素偏移 O(N) 23 | intsetRemove 删除元素 O(N) 24 | 2019-10-11 14:46:31,586 张立志@失业中 说: 25 | 这是实际的时间复杂度 26 | 2019-10-11 14:47:38,118 张立志@失业中 说: 27 | 后边看了一些文章，总结两点，第一官方给的时间复杂度，是理想状态下参考时间复杂度 28 | 2019-10-11 14:48:13,393 张立志@失业中 说: 29 | 第二 intset 有一个512的限制，个人理解用时间换空间 30 | 2019-10-11 14:49:26,097 张立志@失业中 说: 31 | 从目前来看，个人理解可能有出入，有更官方的说法，可以继续讨论 32 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2019-10-15.log: -------------------------------------------------------------------------------- 1 | 2019-10-15 12:29:46,412 鹏程@CMBC 说: 2 | 有想听的，想给大家分享的都可以拿出来，围绕着Redis的什么话题都行，聊聊应用场景，聊聊云服务，聊聊内核，都欢迎 3 | 2019-10-15 12:29:46,738 鹏程@CMBC 说: 4 | 有想听的，想给大家分享的都可以拿出来，围绕着Redis的什么话题都行，聊聊应用场景，聊聊云服务，聊聊内核，都欢迎 5 | 2019-10-15 12:47:06,336 鹏程@CMBC 说: 6 | @陈宝仪@Redis-replicator 找一个你能北京的周末，哈哈~ 7 | 2019-10-15 12:47:06,667 鹏程@CMBC 说: 8 | @陈宝仪@Redis-replicator 找一个你能北京的周末，哈哈~ 9 | 2019-10-15 12:47:52,202 陈宝仪@Redis-replicator 说: 10 | 周末的话参加一哈 11 | 2019-10-15 12:47:53,530 陈宝仪@Redis-replicator 说: 12 | 周末的话参加一哈 13 | 2019-10-15 12:49:53,904 鹏程@CMBC 说: 14 | @陈宝仪@Redis-replicator 你来讲讲这几年做replicator和其他几个Redis开源项目的体会呗 15 | 2019-10-15 12:49:54,227 鹏程@CMBC 说: 16 | @陈宝仪@Redis-replicator 你来讲讲这几年做replicator和其他几个Redis开源项目的体会呗 17 | 2019-10-15 12:50:00,262 鹏程@CMBC 说: 18 | 很想听... 19 | 2019-10-15 12:50:00,568 鹏程@CMBC 说: 20 | 很想听... 21 | 2019-10-15 12:52:31,557 陈宝仪@Redis-replicator 说: 22 | 我没有演讲技能树。我还是做个听众吧 23 | 2019-10-15 12:52:31,844 陈宝仪@Redis-replicator 说: 24 | 我没有演讲技能树。我还是做个听众吧 25 | 2019-10-15 13:06:20,865 鹏程@CMBC 说: 26 | 正好借着这种完完全全非正式的场合建立起来岂不更好~ 27 | 2019-10-15 13:06:21,406 鹏程@CMBC 说: 28 | 正好借着这种完完全全非正式的场合建立起来岂不更好~ 29 | -------------------------------------------------------------------------------- /ChatRecords/redisgroup.2020-01-02.log: -------------------------------------------------------------------------------- 1 | 2019-10-17 00:09:40,227 鹏程@CMBC 分享链接: 2 | #每日分享 「链接」 Python Redis 客户端连接池解析 3 | https://t.zsxq.com/Aiiia2f 4 | 2019-10-17 00:09:42,904 鹏程@CMBC 分享链接: 5 | #每日分享 「链接」 Python Redis 客户端连接池解析 6 | https://t.zsxq.com/Aiiia2f 7 | 2019-10-17 02:40:02,900 焦清波@fh 说: 8 | 请问下redis目前有鉴权机制吗，比如针对不同的用户授予读，写，管理集群的权限 9 | 2019-10-17 02:40:04,152 焦清波@fh 说: 10 | 请问下redis目前有鉴权机制吗，比如针对不同的用户授予读，写，管理集群的权限 11 | 2019-10-17 02:43:27,012 陈宝仪@Redis-replicator 说: 12 | 没有，在redis 6会引入acl 13 | 2019-10-17 02:43:28,092 陈宝仪@Redis-replicator 说: 14 | 没有，在redis 6会引入acl 15 | 2019-10-17 02:44:11,447 鹏程@CMBC 说: 16 | 等6吧 17 | 2019-10-17 02:44:11,766 鹏程@CMBC 说: 18 | 等6吧 19 | 2019-10-17 02:47:27,492 焦清波@fh 说: 20 | 好的👌 多谢了 21 | 2019-10-17 02:47:27,807 焦清波@fh 说: 22 | 好的👌 多谢了 23 | 2019-12-31 01:44:45,048 鹏程@CMBC 分享链接: 24 | #每日分享 Automatic Redis Clustering 「链接」 Automatic Redis Clustering - YouTube 25 | https://t.zsxq.com/nMBIAYJ 26 | 2020-01-02 17:04:41,393 杨玉辉@北京物通 说: 27 | 大佬们问个问题 28 | 我这个key在redis里面存储值为095360 用redis-cli客户端取到的值也是这个 29 | 为什么用redisTemplate 取出来前面的0就没了呢，取到的值为95360 如果存的这个值开头不为0就没有这种情况 30 | 2020-01-02 20:02:35,732 吴楚伟@利郎达 说: 31 | 类型转换了 32 | 2020-01-02 21:13:13,631 肖贝贝@BIGO 说: 33 | get 是个模板方法? 34 | -------------------------------------------------------------------------------- /CodeDesignRule/README.md: -------------------------------------------------------------------------------- 1 | # 4. 开发设计规范 -------------------------------------------------------------------------------- /CodeDesignRule/app1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/app1.png -------------------------------------------------------------------------------- /CodeDesignRule/client.md: -------------------------------------------------------------------------------- 1 | #4.7 客户端推荐 2 | ##4.7.1 Redis-Python驱动的安装和使用 3 | unzip redis-py-master.zip 4 | cd redis-py-master/ 5 | sudo python setup.py install 6 | 7 | 完成后import redis即可。 8 | 9 | 10 | 11 | ##4.7.2 Redis-Java客户端推荐 12 | 13 | 1. Jedis ：https://github.com/xetorthio/jedis 重点推荐 14 | 2. Spring Data redis ：https://github.com/spring-projects/spring-data-redis 使用Spring框架时推荐 15 | 3. Redisson ：https://github.com/mrniko/redisson 分布式锁、阻塞队列的时重点推荐 16 | 17 | 18 | ##4.7.3 Redis-C客户端推荐 19 | Hiredis是redis数据库一个官方推荐的C语言redis client库。 20 | -------------------------------------------------------------------------------- /CodeDesignRule/dataexception.md: -------------------------------------------------------------------------------- 1 | #4.3 数据异常处理 2 | 程序应该处理如果redis数据丢失时的清理redis内存和重新加载的过程。 3 | -------------------------------------------------------------------------------- /CodeDesignRule/expire.md: -------------------------------------------------------------------------------- 1 | #4.2 超时设置 2 | 从业务需求逻辑和内存的角度，尽可能的设置key存活时间。 3 | -------------------------------------------------------------------------------- /CodeDesignRule/keydesign.md: -------------------------------------------------------------------------------- 1 | #4.1 Key设计 2 | key的一个格式约定：`object-type:id:field`。用":"分隔域，用"."作为单词间的连接，如"`comment:12345:reply.to`"。不推荐含义不清的key和特别长的key。 3 | 4 | 一般的设计方法如下： 5 | 1: 把表名转换为key前缀 如, tag: 6 | 2: 第2段放置用于区分区key的字段--对应mysql中的主键的列名,如userid 7 | 3: 第3段放置主键值,如2,3,4...., a , b ,c 8 | 4: 第4段,写要存储的列名 9 | 10 | 例如用户表 user, 转换为key-value存储： 11 | 12 | 13 | userid|username|password|email 14 | :---------------|:---------------|:---------------|:--------------- 15 | 9|lisi|1111111|lisi@163.com 16 | 17 | 18 | set user:userid:9:username lisi 19 | set user:userid:9:password 111111 20 | set user:userid:9:email lisi@163.com 21 | 22 | 例如，查看某个用户的所有信息为： 23 | 24 | keys user:userid:9* 25 | 26 | 如果另一个列也常常被用来查找，比如username，则也要相应的生成一条按照该列为主的key-value，例如： 27 | 28 | user:username:lisi:uid 9 29 | 30 | 此时相当于RDBMS中在username上加索引，我们可以根据 31 | `username:lisi:uid `,查出userid=9，再查`user:9:password/email` ... 32 | -------------------------------------------------------------------------------- /CodeDesignRule/lat1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/lat1.png -------------------------------------------------------------------------------- /CodeDesignRule/lat2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/lat2.png -------------------------------------------------------------------------------- /CodeDesignRule/lat3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/lat3.png -------------------------------------------------------------------------------- /CodeDesignRule/lat4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/lat4.png -------------------------------------------------------------------------------- /CodeDesignRule/mem1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/mem1.png -------------------------------------------------------------------------------- /CodeDesignRule/mem2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/mem2.png -------------------------------------------------------------------------------- /CodeDesignRule/mem3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/mem3.png -------------------------------------------------------------------------------- /CodeDesignRule/redis命令参考.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/CodeDesignRule/redis命令参考.pdf -------------------------------------------------------------------------------- /DataStructure/README.md: -------------------------------------------------------------------------------- 1 | # 2. 数据操作 2 | 熟悉每个数据操作前一定要明白每个操作都是代价，以时间复杂度和对应查询集或者结果集大小为衡量。时间复杂度收敛状况如下： 3 | 4 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/timecomplex.gif) -------------------------------------------------------------------------------- /DataStructure/hash/README.md: -------------------------------------------------------------------------------- 1 | 底层实现是hash table，一般操作复杂度是O(1)，要同时操作多个field时就是O(N)，N是field的数量。应用场景：土法建索引。比如User对象，除了id有时还要按name来查询。 2 | 3 | 可以有如下的数据记录: 4 | (String) user:101 -> {"id":101,"name":"calvin"...} 5 | (String) user:102 -> {"id":102,"name":"kevin"...} 6 | (Hash) user:name:index-> "calvin"->101, "kevin" -> 102 7 | -------------------------------------------------------------------------------- /DataStructure/hash/hdel.md: -------------------------------------------------------------------------------- 1 | #2.6.5 删除域 2 | hdel key field 3 | 删除指定的hash field 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hexists.md: -------------------------------------------------------------------------------- 1 | #2.6.4 判断某一个域是否存在 2 | hexists key field 3 | 测试指定field是否存在 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hget.md: -------------------------------------------------------------------------------- 1 | #2.6.2 获取hash值 2 | 3 | hget key field 4 | 获取指定的hash field 5 | 6 | hmget key filed1....fieldN 7 | 获取全部指定的hash filed 8 | 9 | hmset key filed1 value1 ... filedN valueN 10 | 同时设置hash的多个field 11 | 12 | -------------------------------------------------------------------------------- /DataStructure/hash/hgetall.md: -------------------------------------------------------------------------------- 1 | #2.6.9 获取所有域名和值 2 | hgetall 3 | 返回hash的所有filed和value 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hincrby.md: -------------------------------------------------------------------------------- 1 | #2.6.3 递增某一个域的值 2 | hincrby key field integer 3 | 将指定的hash filed 加上给定值 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hkeys.md: -------------------------------------------------------------------------------- 1 | #2.6.7 获取所有的域名 2 | hkeys key 3 | 返回hash的所有field 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hlen.md: -------------------------------------------------------------------------------- 1 | #2.6.6 获取域的数量 2 | hlen key 3 | 返回指定hash的field数量 4 | -------------------------------------------------------------------------------- /DataStructure/hash/hset.md: -------------------------------------------------------------------------------- 1 | #2.6.1 设置hash值 2 | 3 | hset key field value 4 | 设置hash field为指定值，如果key不存在，则先创建。 5 | 6 | hsetnx 7 | 设置hash field为指定值，如果 key 不存在，则先创建。如果 field已经存在，返回0，nx是not exist的意思。 8 | 9 | -------------------------------------------------------------------------------- /DataStructure/hash/hvals.md: -------------------------------------------------------------------------------- 1 | #2.6.8 获取所有域的值 2 | hvals key 3 | 返回hash的所有value 4 | -------------------------------------------------------------------------------- /DataStructure/hyperloglog/README.md: -------------------------------------------------------------------------------- 1 | # 2.7 HyperLogLog操作 2 | HyperLogLog主要解决大数据应用中的非精确计数（可能多也可能少，但是会在一个合理的范围）操作，它可以接受多个元素作为输入，并给出输入元素的基数估算值，基数指的是集合中不同元素的数量。比如 {'apple', 'banana', 'cherry', 'banana', 'apple'} 的基数就是 3 。 3 | HyperLogLog 的优点是，即使输入元素的数量或者体积非常非常大，计算基数所需的空间总是固定的、并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。 4 | 5 | 关于这个数据类型的误差：在一个大小为12k的key所存储的hyperloglog集合基数计算的误差是%0.81. 6 | 7 | 参考文献：http://highscalability.com/blog/2012/4/5/big-data-counting-how-to-count-a-billion-distinct-objects-us.html 8 | -------------------------------------------------------------------------------- /DataStructure/hyperloglog/pfadd.md: -------------------------------------------------------------------------------- 1 | #2.7.1 将元素添加至 HyperLogLog 2 | PFADD key element [element ...] 3 | 这个命令可能会对 HyperLogLog 进行修改，以便反映新的基数估算值，如果 HyperLogLog 的基数估算值在命令执行之后出现了变化， 那么命令返回 1 ， 否则返回 0 。 命令的复杂度为 O(N) ，N 为被添加元素的数量。 4 | -------------------------------------------------------------------------------- /DataStructure/hyperloglog/pfcount.md: -------------------------------------------------------------------------------- 1 | #2.7.2 返回给定 HyperLogLog 的基数估算值 2 | PFCOUNT key [key ...] 3 | 当只给定一个 HyperLogLog 时，命令返回给定 HyperLogLog 的基数估算值。当给定多个 HyperLogLog 时，命令会先对给定的 HyperLogLog 进行并集计算，得出一个合并后的 HyperLogLog ，然后返回这个合并 HyperLogLog 的基数估算值作为命令的结果（合并得出的 HyperLogLog 不会被储存，使用之后就会被删掉）。 4 | 当命令作用于单个 HyperLogLog 时， 复杂度为 O(1) ， 并且具有非常低的平均常数时间。 5 | 当命令作用于多个 HyperLogLog 时， 复杂度为 O(N) ，并且常数时间也比处理单个 HyperLogLog 时要大得多。 6 | -------------------------------------------------------------------------------- /DataStructure/hyperloglog/pfmerge.md: -------------------------------------------------------------------------------- 1 | #2.7.3 合并多个 HyperLogLog 2 | PFMERGE destkey sourcekey [sourcekey ...] 3 | 将多个 HyperLogLog 合并为一个 HyperLogLog ，合并后的 HyperLogLog 的基数估算值是通过对所有给定 HyperLogLog 进行并集计算得出的。 4 | 命令的复杂度为 O(N) ， 其中 N 为被合并的 HyperLogLog 数量， 不过这个命令的常数复杂度比较高。 5 | -------------------------------------------------------------------------------- /DataStructure/key/README.md: -------------------------------------------------------------------------------- 1 | # 2.1. key操作 2 | redis 的key操作是涉及范围最广的操作 。 -------------------------------------------------------------------------------- /DataStructure/key/del.md: -------------------------------------------------------------------------------- 1 | # 2.1.3 删除给定key 2 | 3 | del key1 key2 ....keyN 4 | 5 | 返回成功删除的key的个数 6 | -------------------------------------------------------------------------------- /DataStructure/key/exist.md: -------------------------------------------------------------------------------- 1 | # 2.1.2 测试指定key是否存在 2 | 3 | exists key 4 | 5 | 返回1表示存在，0不存在 -------------------------------------------------------------------------------- /DataStructure/key/expire.md: -------------------------------------------------------------------------------- 1 | #2.1.7 Key的超时设置处理 2 | expire key seconds 3 | 单位是秒。返回1成功，0表示key已经设置过过期时间或者不存在。 4 | 如果想消除超时则使用persist key。如果希望采用绝对超时，则使用expireat命令。 5 | 6 | ---------- 7 | 8 | ttl key 9 | 返回设置过过期时间的key的剩余过期秒数 -1表示没有设置过过期时间，对于不存在的key,返回-2。 10 | 11 | 12 | ---------- 13 | 14 | pexpire key 毫秒数 15 | 16 | 设置生命周期。 17 | 18 | ---------- 19 | 20 | pttl key 21 | 以毫秒返回生命周期。 22 | 23 | ---------- 24 | 25 | >注意： 26 | > 27 | > 当client主动访问key会先对key进行超时判断，过时的key会立刻删除。 28 | > 29 | > 如果clien永远都不再get那条key呢？ 它会在Master的后台，每秒10次的执行如下操作： 随机选取100个key校验是否过期，如果有25个以上的key过期了，立刻额外随机选取下100个key(不计算在10次之内)。可见，如果过期的key不多，它最多每秒回收200条左右，如果有超过25%的key过期了，它就会做得更多，但只要key不被主动get，它占用的内存什么时候最终被清理掉只有天知道。 30 | > 31 | > 在主从复制环境中，由于上述原因存在已经过期但是没有删除的key，在主snapshot时并不包含这些key，因此在slave环境中我们往往看到dbsize较master是更小的。 32 | -------------------------------------------------------------------------------- /DataStructure/key/list.md: -------------------------------------------------------------------------------- 1 | # 2.1.1 列出key 2 | keys *user* 3 | keys * 4 | 5 | 有3个通配符 *, ? ,[] 6 | - *: 通配任意多个字符 7 | - ?: 通配单个字符 8 | - []: 通配括号内的某1个字符 9 | 10 | > 注：生产已经禁止。更安全的做法是采用scan，原理和操作如下： 11 | > ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/key/scan-intro.png) 12 | > 13 | > 针对Keys的改进，支持分页查询Key。在迭代过程中，Keys有增删时不会要锁定写操作，数据集完整度不做任何保证，同一条key可能会被返回多次. 14 | > 15 | > ![](https://raw.githubusercontent.com/gnuhpc/All-About- 16 | Redis/master/DataStructure/key/scan.png) 17 | > ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/key/scan-compare.png) 18 | > 对于其他危险的命令，新版本也进行了替代： 19 | > ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/key/scan-other.png) 20 | 21 | 22 | 23 | redis-cli下的扫描: 24 | 25 | redis-cli --scan --pattern 'chenqun_*' 26 | 27 | 28 | 这是用scan命令扫描redis中的key，--pattern选项指定扫描的key的pattern。相比keys *pattern*模式,不会长时间阻塞redis而导致其他客户端的命令请求一直处于阻塞状态。 29 | 30 | > 本页中采用了小象学院的两张片子，版权归 [http://www.chinahadoop.cn/](http://www.chinahadoop.cn/) 所有 31 | -------------------------------------------------------------------------------- /DataStructure/key/randomkey.md: -------------------------------------------------------------------------------- 1 | # 2.1.5 返回从当前数据库中随机选择的一个key 2 | 3 | randomkey 4 | 5 | 如果当前数据库是空的，返回空串 -------------------------------------------------------------------------------- /DataStructure/key/rename.md: -------------------------------------------------------------------------------- 1 | #2.1.6 原子的重命名一个key 2 | 3 | rename oldkey newkey 4 | 5 | 如果newkey存在，将会被覆盖，返回OK表示成功，如果失败，则可能是oldkey不存在或者和newkey相同，返回具体错误信息。 6 | 7 | 8 | renamenx oldkey newkey 9 | 同上，成功返回1，失败返回0，如果newkey存在的话。 10 | -------------------------------------------------------------------------------- /DataStructure/key/scan-compare.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/key/scan-compare.png -------------------------------------------------------------------------------- /DataStructure/key/scan-intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/key/scan-intro.png -------------------------------------------------------------------------------- /DataStructure/key/scan-other.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/key/scan-other.png -------------------------------------------------------------------------------- /DataStructure/key/scan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/key/scan.png -------------------------------------------------------------------------------- /DataStructure/key/type.md: -------------------------------------------------------------------------------- 1 | # 2.1.4 返回给定key的value类型 2 | 3 | type key 4 | 5 | 返回 none 表示不存在key。string字符类型，list 链表类型 set 无序集合类型... -------------------------------------------------------------------------------- /DataStructure/list/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/list/README.md -------------------------------------------------------------------------------- /DataStructure/list/addlist.md: -------------------------------------------------------------------------------- 1 | #2.3.1 添加元素 2 | lpush key string 3 | 在key对应list的头部添加字符串元素，返回1表示成功，0表示key存在且不是list类型。注意：江湖规矩一般从左端Push，右端Pop，即LPush/RPop。 4 | 5 | --- 6 | lpushx 7 | 也是将一个或者多个value插入到key列表的表头，但是如果key不存在，那么就什么都不在，返回一个false【rpushx也是同样】 8 | 9 | --- 10 | rpush key string 11 | 同上，在尾部添加 12 | 13 | --- 14 | linsert 15 | 在key对应list的特定位置之前或之后添加字符串元素 , 例如 16 | 17 | redis 127.0.0.1:6379linsert mylist3 before "world" "there" 18 | -------------------------------------------------------------------------------- /DataStructure/list/blocklist.md: -------------------------------------------------------------------------------- 1 | #2.3.8 阻塞队列 2 | 3 | blpop key1...keyN timeout 4 | 5 | 从左到右扫描返回对第一个非空list进行lpop操作并返回，比如blpop list1 list2 list3 0 ,如果list不存在list2,list3都是非空则对list2做lpop并返回从list2中删除的元素。如果所有的list都是空或不存在，则会阻塞timeout秒，timeout为0表示一直阻塞。当阻塞时，如果有client对key1...keyN中的任意key进行push操作，则第一在这个key上被阻塞的client会立即返回（返回键和值）。如果超时发生，则返回nil。有点像unix的select或者poll。 6 | 7 | brpop 8 | 同blpop，一个是从头部删除一个是从尾部删除。 9 | 10 | > 注意：不要采用其作为ajax的服务端推送，因为连接有限，遇到问题连接直接打满。 11 | 12 | 13 | BLPOP/BRPOP 的先到先服务原则 14 | 如果有多个客户端同时因为某个列表而被阻塞，那么当有新值被推入到这个列表时，服务器会按照先到先服务（first in first service）原则，优先向最早被阻塞的客户端返回新值。举个例子，假设列表 lst 为空，那么当客户端 X 执行命令 BLPOP lst timeout 时，客户端 X 将被阻塞。在此之后，客户端 Y 也执行命令 BLPOP lst timeout ，也因此被阻塞。如果这时，客户端 Z 执行命令 RPUSH lst "hello" ，将值 "hello" 推入列表 lst ，那么这个 "hello" 将被返回给客户端 X ，而不是客户端 Y ，因为客户端 X 的被阻塞时间要早于客户端 Y 的被阻塞时间。 15 | 16 | rpoplpush/brpoplpush：rpoplpush srckey destkey 从srckey对应list的尾部移除元素并添加到destkey对应list的头部,最后返回被移除的元素值，整个操作是原子的.如果srckey是空或者不存在返回nil，注意这是唯一一个操作两个列表的操作，用于两个队列交换消息。 17 | 18 | 应用场景：task + bak 双链表完成工作任务转交的安全队列，保证原子性。 19 | 业务逻辑: 20 | 1: Rpoplpush task bak 21 | 2: 接收返回值,并做业务处理 22 | 3: 完成时用LREM消掉。如不成功或者如果集群管理(如zookeeper)发现worker已经挂掉,下次从bak表里取任务 23 | 24 | 另一个应用场景是循环链表： 25 | 127.0.0.1:6379> lrange list 0 -1 26 | 1) "c" 27 | 2) "b" 28 | 3) "a" 29 | 127.0.0.1:6379> rpoplpush list list 30 | "a" 31 | 127.0.0.1:6379> lrange list 0 -1 32 | 1) "a" 33 | 2) "c" 34 | 3) "b" 35 | -------------------------------------------------------------------------------- /DataStructure/list/del.md: -------------------------------------------------------------------------------- 1 | #2.3.6 删除元素 2 | 3 | lrem key count value 4 | 从key对应list中删除count个和value相同的元素。count为0时候删除全部，count为正，则删除匹配count个元素，如果为负数，则是从右侧扫描删除匹配count个元素。复杂度是O(N)，N是List长度，因为List的值不唯一，所以要遍历全部元素，而Set只要O(log(N))。 5 | 6 | --- 7 | lpop key 8 | 从list的头部删除元素，并返回删除元素。如果key对应list不存在或者是空返回nil，如果key对应值不是list返回错误。 9 | 10 | --- 11 | rpop 12 | 同上，但是从尾部删除。 13 | -------------------------------------------------------------------------------- /DataStructure/list/lindex.md: -------------------------------------------------------------------------------- 1 | #2.3.3 查看元素 2 | lindex 3 | 返回名称为key的list中index位置的元素，例如： 4 | 5 | redis 127.0.0.1:6379> lindex mylist5 0 6 | -------------------------------------------------------------------------------- /DataStructure/list/llen.md: -------------------------------------------------------------------------------- 1 | #2.3.2 查看列表长度 2 | llen key 3 | 返回key对应list的长度，key不存在返回0,如果key对应类型不是list返回错误 -------------------------------------------------------------------------------- /DataStructure/list/lrange.md: -------------------------------------------------------------------------------- 1 | #2.3.4 查看一段列表 2 | 3 | lrange key start end 4 | 返回指定区间内的元素，下标从0开始，负值表示从后面计算，-1表示倒数第一个元素 ，key不存在返回空列表。特殊的， 5 | 6 | lrange key 0 -1 7 | 返回所有数据。 -------------------------------------------------------------------------------- /DataStructure/list/lset.md: -------------------------------------------------------------------------------- 1 | #2.3.7 设置list中指定下标的元素值 2 | 3 | lset key index value 4 | 成功返回1，key或者下标不存在返回错误 -------------------------------------------------------------------------------- /DataStructure/list/ltrim.md: -------------------------------------------------------------------------------- 1 | #2.3.5 截取list 2 | 3 | ltrim key start end 4 | 5 | 保留指定区间内元素，成功返回1，key不存在返回错误。O(N)操作。 6 | 7 | 8 | 9 | > 注意：N是被移除的元素的个数，不是列表长度。 -------------------------------------------------------------------------------- /DataStructure/set/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/set/README.md -------------------------------------------------------------------------------- /DataStructure/set/sadd.md: -------------------------------------------------------------------------------- 1 | # 2.4.1 添加元素 2 | sadd key member 3 | 4 | 成功返回1,如果元素以及在集合中返回0,key对应的set不存在返回错误 5 | -------------------------------------------------------------------------------- /DataStructure/set/scard.md: -------------------------------------------------------------------------------- 1 | #2.4.6 查看集合大小 2 | scard key 3 | 如果set是空或者key不存在返回0 4 | -------------------------------------------------------------------------------- /DataStructure/set/sdiff.md: -------------------------------------------------------------------------------- 1 | #2.4.10 集合差集 2 | 3 | sdiff key1 key2...keyN 4 | 返回所有给定key的差集 5 | 6 | --- 7 | sdiffstore dstkey key1...keyN 8 | 同sdiff，并同时保存差集到dstkey下 9 | -------------------------------------------------------------------------------- /DataStructure/set/sinter.md: -------------------------------------------------------------------------------- 1 | #2.4.8 集合交集 2 | sinter key1 key2...keyN 3 | 返回所有给定key的交集 4 | 5 | --- 6 | sinterstore dstkey key1...keyN 7 | 同sinter，但是会同时将交集存到dstkey下 8 | -------------------------------------------------------------------------------- /DataStructure/set/sismember.md: -------------------------------------------------------------------------------- 1 | #2.4.7 判断member是否在set中 2 | sismember key member 3 | 存在返回1，0表示不存在或者key不存在 4 | -------------------------------------------------------------------------------- /DataStructure/set/smembers.md: -------------------------------------------------------------------------------- 1 | #2.4.11 获取所有元素 2 | smembers key 3 | 返回key对应set的所有元素，结果是无序的，集合元素很多时会阻塞，**生产上禁用！ 4 | ** -------------------------------------------------------------------------------- /DataStructure/set/smove.md: -------------------------------------------------------------------------------- 1 | #2.4.5 集合间移动元素 2 | smove srckey dstkey member 3 | 从srckey对应set中移除member并添加到dstkey对应set中，整个操作是原子的。成功返回1,如果member在srckey中不存在返回0，如果key不是set类型返回错误 4 | -------------------------------------------------------------------------------- /DataStructure/set/spop.md: -------------------------------------------------------------------------------- 1 | #2.4.3 删除并返回元素 2 | spop key 3 | 如果set是空或者key不存在返回nil 4 | -------------------------------------------------------------------------------- /DataStructure/set/srandmember.md: -------------------------------------------------------------------------------- 1 | #2.4.4 随机返回一个元素 2 | srandmember key 3 | 同spop，随机取set中的一个元素，但是不删除元素 4 | -------------------------------------------------------------------------------- /DataStructure/set/srem.md: -------------------------------------------------------------------------------- 1 | #2.4.2 移除元素 2 | srem key member 3 | 成功返回1，如果member在集合中不存在或者key不存在返回0，如果key对应的不是set类型的值返回错误 4 | -------------------------------------------------------------------------------- /DataStructure/set/sunion.md: -------------------------------------------------------------------------------- 1 | #2.4.9 集合并集 2 | sunion key1 key2...keyN 3 | 返回所有给定key的并集 4 | 5 | --- 6 | sunionstore dstkey key1...keyN 7 | 同sunion，并同时保存并集到dstkey下 8 | -------------------------------------------------------------------------------- /DataStructure/string/README.md: -------------------------------------------------------------------------------- 1 | 最大字符串为512M，但是大字符串非常不建议。 -------------------------------------------------------------------------------- /DataStructure/string/append.md: -------------------------------------------------------------------------------- 1 | #2.2.4 追加字符串 2 | 3 | append key value 4 | 返回新字符串值的长度。 -------------------------------------------------------------------------------- /DataStructure/string/bit1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/bit1.png -------------------------------------------------------------------------------- /DataStructure/string/bit2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/bit2.png -------------------------------------------------------------------------------- /DataStructure/string/bitop.md: -------------------------------------------------------------------------------- 1 | #2.2.10 位操作 2 | 3 | **注意：位操作中的位置是反过来的，offset过大,则会在中间填充0，比如 SETBIT bit 0 1，此时bit为10000000，此时再进行SETBIT bit 7 1，此时bit为10000001。offset最大2^32-1。** 4 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/bit2.png) 5 | 6 | 7 | GETBIT key offset / SETBIT key offset value 8 | 设置某个索引的位为0/1 9 | 10 | bitcount 11 | 对位进行统计 12 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/bit1.png) 13 | 14 | bitop 15 | 对1个或多个key对应的值进行AND/OR/XOR/NOT操作 16 | 17 | 注意: 18 | >1.bitop操作避免阻塞应尽量移到slave上操作. 19 | >2.对于NOT操作, key不能多个 20 | -------------------------------------------------------------------------------- /DataStructure/string/chinese.md: -------------------------------------------------------------------------------- 1 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/chinese.png) -------------------------------------------------------------------------------- /DataStructure/string/chinese.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/chinese.png -------------------------------------------------------------------------------- /DataStructure/string/get.md: -------------------------------------------------------------------------------- 1 | #2.2.2 获取key对应的string值 2 | 3 | get key 4 | 如果key不存在返回nil 5 | 6 | --- 7 | 8 | getset key value 9 | 原子的设置key的值，并返回key的旧值。如果key不存在返回nil。应用场景：设置新值，返回旧值，配合setnx可实现分布式锁。 10 | 11 | 分布式锁的思路：注意该思路要保证多台Client服务器的NTP一致。 12 | 1. C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0 13 | 2. C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。 14 | 3. 反之，如果已超时，C3通过下面的操作来尝试获得锁： 15 | 4. GETSET lock.foo 16 | 5. 通过GETSET，C3拿到的时间戳如果仍然是超时的，那就说明，C3如愿以偿拿到锁了。 17 | 6. 如果在C3之前，有个叫C4的客户端比C3快一步执行了上面的操作，那么C3拿到的时间戳是个未超时的值，这时，C3没有如期获得锁，需要再次等待或重试。留意一下，尽管C3没拿到锁，但它改写了C4设置的锁的超时值，不过这一点非常微小的误差带来的影响可以忽略不计。 18 | 19 | 伪代码为： 20 | # get lock 21 | lock = 0 22 | while lock != 1: 23 | timestamp = current Unix time + lock timeout + 1 24 | lock = SETNX lock.foo timestamp 25 | if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)): 26 | break; 27 | else: 28 | sleep(10ms) 29 | 30 | # do your job 31 | do_job() 32 | 33 | # release 34 | if now() < GET lock.foo: 35 | DEL lock.foo 36 | 37 | 以上是一个单Server 的分布式锁思路，官网上还介绍了另一个单机使用超时方式进行的思路，和这个基本一致，并且在同一个文档中介绍了一个名为redlock的多Server容错型分布式锁的算法，同时列出了多语言的实现。这个算法的优势在于几个服务器可以有少量的时间差，不要求严格时间一致。 38 | 39 | 也可以设计一个按小时计算的计数器，可以用GetSet获取计数并重置为0。 40 | 41 | --- 42 | mget key1 key2 ... keyN 43 | 一次获取多个key的值，如果对应key不存在，则对应返回nil 44 | -------------------------------------------------------------------------------- /DataStructure/string/getrange.md: -------------------------------------------------------------------------------- 1 | #2.2.7 返回子字符串 2 | GETRANGE key start end 3 | 4 | 返回key 中字符串值的子字符串，字符串的截取范围由start 和end 两个偏移量决定(包括start 和end 在内)。可以使用负值，字符串右面下标是从-1开始的。 5 | 6 | 注意返回值处理： 7 | 1: start>=length, 则返回空字符串 8 | 2: stop>=length,则截取至字符结尾 9 | 3: 如果start 所处位置在stop右边, 返回空字符串 10 | -------------------------------------------------------------------------------- /DataStructure/string/incr1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/incr1.png -------------------------------------------------------------------------------- /DataStructure/string/incrdecr.md: -------------------------------------------------------------------------------- 1 | incr key 2 | 对key的值做加加操作,并返回新的值。注意incr一个不是int的value会返回错误，incr一个不存在的key，则设置key为1。范围为64有符号，-9223372036854775808~9223372036854775807。 3 | 4 | ---------- 5 | 6 | decr key 7 | 同上，但是做的是减减操作，decr一个不存在key，则设置key为-1 8 | 9 | --- 10 | 11 | incrby key integer 12 | 同incr，加指定值 ，key不存在时候会设置key，并认为原来的value是 0 13 | 14 | --- 15 | decrby key integer 16 | 同decr，减指定值。decrby完全是为了可读性，我们完全可以通过incrby一个负值来实现同样效果，反之一样。 17 | 18 | --- 19 | incrbyfloat key floatnumber 20 | 针对浮点数 21 | 22 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/incrfloat.png) 23 | 24 | ---- 25 | 26 | 哪些可以被操作呢？ 27 | 28 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/incr1.png) 29 | 30 | 31 | ---- 32 | 这个操作的应用场景：计数器 33 | -------------------------------------------------------------------------------- /DataStructure/string/incrfloat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/incrfloat.png -------------------------------------------------------------------------------- /DataStructure/string/set.md: -------------------------------------------------------------------------------- 1 | #2.2.1 设置key对应的值为string类型的value 2 | set key value [ex 秒数] / [px 毫秒数] [nx] /[xx] 3 | 4 | 返回1表示成功，0失败 5 | > 注: 如果ex,px同时写,以后面的有效期为准 6 | 7 | ---------- 8 | 9 | setnx key value 10 | 仅当key不存在时才Set，如果key已经存在，返回0 。nx 是not exist的意思。 11 | 12 | > 应用场景：用来选举Master或做分布式锁：所有Client不断尝试使用SetNx master myName抢注Master，成功的那位不断使用Expire刷新它的过期时间。如果Master倒掉了key就会失效，剩下的节点又会发生新一轮抢夺。 13 | 14 | ---------- 15 | 16 | mset key1 value1 ... keyN valueN 17 | 一次设置多个key的值，成功返回1表示所有的值都设置了，失败返回0表示没有任何值被设置 18 | 19 | ---------- 20 | 21 | msetnx key1 value1 ... keyN valueN 22 | 同上，但是不会覆盖已经存在的key 23 | 24 | ---------- 25 | 26 | SET 命令还支持可选的 NX 选项和 XX 选项，例如：SET nx-str "this will fail" XX 27 | - 如果给定了 NX 选项，那么命令仅在键 key 不存在的情况下，才进行设置操作；如果键 key 已经存在，那么 SET ... NX 命令不做动作（不会覆盖旧值）。 28 | - 如果给定了 XX 选项，那么命令仅在键 key 已经存在的情况下，才进行设置操作；如果键 key 不存在，那么 SET ... XX 命令不做动作（一定会覆盖旧值）。在给定 NX 选项和 XX 选项的情况下，SET 命令在设置成功时返回 OK ，设置失败时返回 nil 。 -------------------------------------------------------------------------------- /DataStructure/string/setrange.md: -------------------------------------------------------------------------------- 1 | #2.2.6 改写字符串 2 | SETRANGE key offset value 3 | 用value 参数覆写(overwrite)给定key 所储存的字符串值，从偏移量offset 开始。 不存在的key 当作空白字符串处理。可以用作append： 4 | 5 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/setrange.png) 6 | 7 | >注意: 如果偏移量>字符长度, 该字符自动补0x00，注意它不会报错 8 | >![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/DataStructure/string/setrange0.png) -------------------------------------------------------------------------------- /DataStructure/string/setrange.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/setrange.png -------------------------------------------------------------------------------- /DataStructure/string/setrange0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/string/setrange0.png -------------------------------------------------------------------------------- /DataStructure/string/strlen.md: -------------------------------------------------------------------------------- 1 | #2.2.9 取指定key的value值的长度 2 | 3 | strlen -------------------------------------------------------------------------------- /DataStructure/string/substr.md: -------------------------------------------------------------------------------- 1 | #2.2.5 截取字符串 2 | substr key start end 3 | 返回截取过的key的字符串值,注意并不修改key的值。下标是从0开始的 -------------------------------------------------------------------------------- /DataStructure/timecomplex.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/DataStructure/timecomplex.gif -------------------------------------------------------------------------------- /DataStructure/zset/README.md: -------------------------------------------------------------------------------- 1 | Sorted Set的实现是hash table(element->score, 用于实现ZScore及判断element是否在集合内)，和skip list(score->element,按score排序)的混合体。 skip list有点像平衡二叉树那样，不同范围的score被分成一层一层，每层是一个按score排序的链表。 2 | 3 | ZAdd/ZRem是O(log(N))，ZRangeByScore/ZRemRangeByScore是O(log(N)+M)，N是Set大小，M是结果/操作元素的个数。可见，原本可能很大的N被很关键的Log了一下，1000万大小的Set，复杂度也只是几十不到。当然，如果一次命中很多元素M很大那谁也没办法了。 4 | -------------------------------------------------------------------------------- /DataStructure/zset/ZUNIONSTORE.md: -------------------------------------------------------------------------------- 1 | #2.5.10 评分的聚合 2 | ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight] [AGGREGATE SUM|MIN|MAX] 3 | 4 | 例如： 5 | 6 | 127.0.0.1:6379> zrangebyscore votes -inf inf withscores 7 | 1) "sina" 8 | 2) "1" 9 | 3) "google" 10 | 4) "5" 11 | 5) "baidu" 12 | 6) "10" 13 | 127.0.0.1:6379> zrangebyscore visits -inf inf withscores 14 | 1) "baidu" 15 | 2) "1" 16 | 3) "google" 17 | 4) "5" 18 | 5) "sina" 19 | 6) "10" 20 | 127.0.0.1:6379> zunionstore award 2 visits votes weights 1 2 aggregate sum 21 | (integer) 3 22 | 127.0.0.1:6379> zrangebyscore award -inf inf withscores 23 | 1) "sina" 24 | 2) "12" 25 | 3) "google" 26 | 4) "15" 27 | 5) "baidu" 28 | 6) "21" 29 | 30 | 一个小技巧是如果需要对评分进行倍加，则使用如下的方法： 31 | 32 | 127.0.0.1:6379>zrangebyscore visits -inf inf withscores 33 | 1) "baidu" 34 | 2) "1" 35 | 3) "google" 36 | 4) "5" 37 | 5) "sina" 38 | 6) "10" 39 | 127.0.0.1:6379>zunionstore visits 1 visits weights 2 40 | (integer) 3 41 | 127.0.0.1:6379>zrangebyscore visits -inf inf withscores 42 | 1) "baidu" 43 | 2) "2" 44 | 3) "google" 45 | 4) "10" 46 | 5) "sina" 47 | 6) "20" 48 | -------------------------------------------------------------------------------- /DataStructure/zset/zadd.md: -------------------------------------------------------------------------------- 1 | #2.5.1 添加元素 2 | zadd key score member 3 | 添加元素到集合，元素在集合中存在则更新对应score。 4 | -------------------------------------------------------------------------------- /DataStructure/zset/zcard.md: -------------------------------------------------------------------------------- 1 | #2.5.8 返回集合中元素个数 2 | zcard key 3 | -------------------------------------------------------------------------------- /DataStructure/zset/zcount.md: -------------------------------------------------------------------------------- 1 | #2.5.7 返回集合中score在给定区间的数量 2 | zcount key min max 3 | -------------------------------------------------------------------------------- /DataStructure/zset/zincrby.md: -------------------------------------------------------------------------------- 1 | #2.5.3 增加score 2 | zincrby key incr member 3 | 增加对应member的score值，然后移动元素并保持skip list保持有序。返回更新后的score值，可以为负数递减 4 | -------------------------------------------------------------------------------- /DataStructure/zset/zrange.md: -------------------------------------------------------------------------------- 1 | #2.5.5 获取排行榜 2 | zrange key start end 3 | 类似lrange操作从集合中去指定区间的元素。返回的是有序结果 4 | 5 | --- 6 | zrevrange key start end 7 | 同上，返回结果是按score逆序的,如果需要得分则加上withscores 8 | 9 | > 注：index从start到end的所有元素 10 | -------------------------------------------------------------------------------- /DataStructure/zset/zrangebyscore.md: -------------------------------------------------------------------------------- 1 | #2.5.6 返回给定分数区间的元素 2 | zrangebyscore key min max 3 | 可以指定inf为无穷 4 | -------------------------------------------------------------------------------- /DataStructure/zset/zrank.md: -------------------------------------------------------------------------------- 1 | #2.5.4 获取排名 2 | zrank key member 3 | 返回指定元素在集合中的排名（下标，注意不是分数）,集合中元素是按score从小到大排序的 4 | 5 | --- 6 | zrevrank key member 7 | 同上,但是集合中元素是按score从大到小排序 8 | -------------------------------------------------------------------------------- /DataStructure/zset/zrem.md: -------------------------------------------------------------------------------- 1 | #2.5.2 删除元素 2 | zrem key member 3 | 1表示成功，如果元素不存在返回0 4 | 5 | --- 6 | zremrangebyrank key min max 7 | 删除集合中排名在给定区间的元素 8 | 9 | --- 10 | zremrangebyscore key min max 11 | 删除集合中score在给定区间的元素 12 | -------------------------------------------------------------------------------- /DataStructure/zset/zscore.md: -------------------------------------------------------------------------------- 1 | #2.5.9 返回给定元素对应的score 2 | zscore key element 3 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | FROM python:2.7 2 | COPY ./ /redis/ 3 | COPY ./.git* /root/ 4 | RUN pip install itchat 5 | WORKDIR /redis/ChatRecords 6 | CMD ["python", "syncgroupchat.py"] 7 | -------------------------------------------------------------------------------- /HAClusterArchPractice/README.md: -------------------------------------------------------------------------------- 1 | #11. 高可用和集群架构与实践 2 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/README.md: -------------------------------------------------------------------------------- 1 | #11.1 主从复制-sentinel架构 2 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploy-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/deploy-1.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploy.md: -------------------------------------------------------------------------------- 1 | #11.1.2 环境搭建 -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deployarch.md: -------------------------------------------------------------------------------- 1 | #11.1.2.1 部署架构 2 | 部署架构上采用三台机器，一个Master接受写请求，两个Slave进行数据同步，三台机器上都部署sentinel（一般为奇数个，因为需要绝大部分进行投票才能failover）。（官方示例）具体架构如下图： 3 | 4 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/deploy-1.png) 5 | 6 | 注意：如果有条件可以将sentinel多部署几个在客户端所在的应用服务器上，而不是与从节点部署在一起，这样避免整机宕机后sentinel和slave都减少而导致的切换选举sentinel无法超过半数。 7 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deployconfig.md: -------------------------------------------------------------------------------- 1 | #11.1.2.7 配置文件 2 | 首先，一个sentinel可以配置多个master。一个master的配置如下： 3 | 4 | port 26379 5 | ###定义目录存放 6 | dir "/redis" 7 | ###监控mymaster(可自定义-但只能包括A-z 0-9和”._-”)，注意quorum只影响ODOWN的判断，但是不影响failover，发生failover的条件必须是半数sentinel认为老Master已经ODOWN。此参数建议设置为sentinel/2+1的数值，否则可能会产生脑裂。 8 | sentinel monitor mymaster 192.168.145.131 6379 2 9 | ###mymaster多久不响应认为SDOWN，设置为3100也就是说3次ping失败后认为SDOWN 10 | sentinel down-after-milliseconds mymaster 3100 11 | ###如果在该时间（ms）内未能完成failover操作，则认为该failover失败 12 | sentinel failover-timeout mymaster 15000 13 | 14 | ###在执行故障转移时， 最多可以有多少个从Redis实例在同步新的主实例， 在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长 15 | sentinel parallel-syncs mymaster 1 16 | 17 | ###reconfig的时候执行的脚本（选配） 18 | sentinel client-reconfig-script mymaster /redis/script/failover.sh 19 | 20 | ###出现任何sentinel在warning事件时候执行的脚本（选配） 21 | sentinel notification-script mymaster /redis/script/notify.sh 22 | 23 | ####日志位置 24 | logfile "/redis/log/sentinel.log" 25 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploydict.md: -------------------------------------------------------------------------------- 1 | #11.1.2.5 目录规划 2 | | | | 3 | |---------------|----------------------------| 4 | | 目录 | 含义 | 5 | | /redis/bin | redis可执行文件 | 6 | | /redis/conf | redis 和supervisord的配置文件 | 7 | | /redis/run | redis和supervisord运行时的pid文件 | 8 | | /redis/log | redis和supervisord的日志 | 9 | | /redis/script | 一些管理脚本和测试脚本 | 10 | | /redis/data | Redis持久化数据目录 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploynet.md: -------------------------------------------------------------------------------- 1 | #11.1.2.2 网络规划 2 | redis高可用环境不需要进行心跳线的配置，每个物理节点的网卡进行双网卡主备绑定生成bond0即可。 3 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploypersist.md: -------------------------------------------------------------------------------- 1 | #11.1.2.4 持久化规划 2 | 如果读多写少，可以在master上只开启aof，在低峰期定时进行bgsave，在slave上彻底关闭持久化。 3 | 如果读写差不多，可以在一个slave上开启rdb（这个slave只做持久化，不进行读操作），在其余主从都关闭持久化。 4 | 注意：从节点是不会从本地恢复而直接从master节点进行恢复的，因此在重启前如果有需要备份从节点，则需要把aof和rdb文件移走。 5 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deploystep.md: -------------------------------------------------------------------------------- 1 | #11.1.2.6 部署步骤 2 | 解压下列压缩包至/tmp/redis目录，以符合上述目录结构： 3 | 4 | 5 | 部署相关组件： 6 | cd /tmp/redis/deploy 7 | ./deploy.sh 8 | 9 | 修改Master配置文件redis.conf，注释掉包含slaveof的语句。 10 | 修改Slave配置文件redis.conf，添加slaveof masterIP port，指定主从 11 | 修改三台机器的sentinel配置文件，指定主服务器的IP和端口： 12 | sentinel monitor mymaster masterIP port 2 13 | 14 | 然后使用supervisord重新启动。 15 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/deployuser.md: -------------------------------------------------------------------------------- 1 | #11.1.2.3 用户规划 2 | 3 | | | | | | | 4 | |--------------|---------------|--------|------------------|----| 5 | | 用户名 | 用户所在组 | 用户目录 | 权限 | 备注 | 6 | | redis(10086) | redis (10086) | /redis | sudo（如需要浮动IP时赋予） | -- | 7 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/findprinciple.md: -------------------------------------------------------------------------------- 1 | #12.1.1.1 发现原理 2 | 3 | Sentinel发现分为发现从服务器和发现其他sentinel服务两类： 4 | - Sentinel实例可以通过询问主实例来获得所有从实例的信息 5 | - Sentinel进程可以通过发布与订阅来自动发现正在监视相同主实例的其他Sentinel，每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 \_\_sentinel\_\_:hello 频道， 查找之前未出现过的 sentinel进程。 当一个 Sentinel 发现一个新的 Sentinel 时，它会将新的 Sentinel 添加到一个列表中，这个列表保存了 Sentinel 已知的，监视同一个主服务器的所有其他Sentinel。 6 | 7 | 注：文中的横杠要替换为下滑线，markdown不太能显示出来... -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/haprinciple.md: -------------------------------------------------------------------------------- 1 | #11.1.1 高可用原理 -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-doublesdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.5 双从实例宕测试 2 | 接上，此时Master为2.128，还有一个活着的从2.130，集群状态如下： 3 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest5.png) 4 | 5 | 此时，杀掉2.130的redis实例后，集群状态如下： 6 | 7 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest6.png) 8 | 9 | 此时由于配置了最小slave个数为1，已经不满足，因此集群变为只读状态： 10 | 11 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest7.png) 12 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-doublestdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.7 双sentinel宕测试 2 | 恢复集群状态，2.128为主，2.129、2.130为从。此时，将2.128的sentinel和2.129的sentinel都宕掉。此时主从集群读写均正常。 3 | 在双方sentinel宕机时，杀掉master，主从集群切换失效，原因是因为设置sentinel 的quorum为2，最少有两个sentinel活集群才正常切换。 4 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-env.md: -------------------------------------------------------------------------------- 1 | #11.1.4.1 测试环境介绍 2 | Master：192.168.2.128 （A）:6379 3 | Slave：192.168.2.129 （B）:6379 4 | Slave：192.168.2.130 （B）:6379 5 | Sentinel：三台机器的26379端口 6 | 7 | sentinel的消息可以通过sentinel日志（/redis/log/sentinel.log）以及__sentinel__:hello订阅此频道进行查看。 8 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-masterhang.md: -------------------------------------------------------------------------------- 1 | #11.1.4.12 Master hang死测试 2 | 由于我们的sentinel down-after-milliseconds为3100，即3.1s，因此在master上执行： 3 | debug sleep 3.0，系统不会切换，但是执行debug sleep 3.7或者更大的数值，系统就会判定为主sdown，进而变为odown随后发起投票切换。很难模拟取消odown的，因为时间差很短。 4 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-mastermachdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.8 master所在主机整体宕测试 2 | 恢复集群状态，2.128为主，2.129、2.130为从。此时，对2.128进行宕机测试，直接关闭电源。 3 | 主从切换至2.130,从2.129指向新的主： 4 | 5 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest13.png) 6 | sentinel日志为： 7 | 8 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest14.png) -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-sentinelconf.md: -------------------------------------------------------------------------------- 1 | #11.1.4.13 附：sentinel.conf被修改后的含义 2 | port 26379 3 | dir "/var/lib/redis/tmp" 4 | sentinel monitor mymaster 192.168.65.128 6379 2 5 | sentinel config-epoch mymaster 18 ###确认mymater SDOWN时长 6 | sentinel leader-epoch mymaster 18 ###同时一时间最多18个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务 7 | sentinel known-slave mymaster 192.168.65.129 6379 ###已知的slave 8 | sentinel known-slave mymaster 192.168.65.130 6379 ###已知的slave 9 | sentinel known-sentinel mymaster 192.168.65.130 26379 be964e6330ee1eaa9a6b5a97417e866448c0ae40 ###已知slave的唯一id 10 | sentinel known-sentinel mymaster 192.168.65.129 26379 3e468037d5dda0bbd86adc3e47b29c04f2afe9e6 ###已知slave的唯一id 11 | sentinel current-epoch 18 ####当前可同时同步的salve数最大同步阀值 12 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-singlesdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.4 单从实例宕测试 2 | 接上，2.129为从，此时杀掉该进程，redis.log日志记录如下： 3 | 4 | [14984 | signal handler] (1434674492) Received SIGTERM scheduling shutdown... 5 | [14984] 19 Jun 08:41:32.545 # User requested shutdown... 6 | [14984] 19 Jun 08:41:32.545 * Calling fsync() on the AOF file. 7 | [14984] 19 Jun 08:41:32.545 * Saving the final RDB snapshot before exiting. 8 | [14984] 19 Jun 08:41:32.580 * DB saved on disk 9 | [14984] 19 Jun 08:41:32.580 # Redis is now ready to exit, bye bye... 10 | 11 | 此时集群正常提供对外服务，并不影响。 12 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-singlestdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.6 单sentinel宕测试 2 | 恢复集群状态，2.128为主，2.129、2.130为从。 3 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest8.png) 4 | 此时，从2.128上看sentinel状态： 5 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest9.png) 6 | 由于sentinel都是对等的，在此选择对2.128上的sentinel进行进程宕测试： 7 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest10.png) 8 | 此时，本节点sentinel日志为： 9 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest11.png) 10 | 其他节点sentinel日志为： 11 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest12.png) 12 | 表示2.128上的sentnel已经宕。 13 | 此时集群读写正常，在一个sentinel宕机的基础上宕master后切换正常。 14 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest-slavemachdown.md: -------------------------------------------------------------------------------- 1 | #11.1.4.9 slave所在主机整体宕测试 2 | 恢复集群状态，2.128为主，2.129、2.130为从。此时直接关闭2.129，这时相当于一个redis slave进程和一个sentinel进程宕。主不受影响，并且感知到一个从已经宕机。 3 | 4 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest15.png) 5 | sentinel日志记录了此事件。 6 | 7 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/HAClusterArchPractice/ms/hatest16.png) 8 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest.md: -------------------------------------------------------------------------------- 1 | #11.1.4 高可用和异常测试 -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest1.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest10.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest11.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest12.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest13.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest14.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest15.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest16.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest17.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest18.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest19.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest2.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest20.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest21.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest22.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest23.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest23.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest24.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest25.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest25.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest26.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest27.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest27.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest28.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest28.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest29.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest29.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest3.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest4.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest5.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest6.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest7.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest8.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/hatest9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/hatest9.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-boot.md: -------------------------------------------------------------------------------- 1 | #11.1.3.1 完整启动 2 | 3 | supervisord -c /redis/conf/redis-supervisord.conf 4 | 会自动拉起本机的redis和sentinel 5 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-failover.md: -------------------------------------------------------------------------------- 1 | #11.1.3.10 主动切换 2 | sentinel failover myredis 3 | 此操作会将新的配置发送到其他sentinel上。 4 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-manu-start.md: -------------------------------------------------------------------------------- 1 | #11.1.3.3 手动启动 2 | 有两种方式： 3 | 第一种：redis-sentinel /path/to/sentinel.conf 4 | 第二种：redis-server /path/to/sentinel.conf --sentinel -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-masterconfig.md: -------------------------------------------------------------------------------- 1 | #11.1.3.7 查看master配置 2 | redis-cli -p 26379 sentinel masters 3 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-masteripport.md: -------------------------------------------------------------------------------- 1 | #11.1.3.6 查看master地址和端口 2 | sentinel get-master-addr-by-name myredis 3 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-modifyconf.md: -------------------------------------------------------------------------------- 1 | #11.1.3.9 动态修改sentinel配置 2 | SENTINEL SET command 3 | 例如： 4 | 5 | SENTINEL SET objects-cache-master down-after-milliseconds 1000 6 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-msconsistence.md: -------------------------------------------------------------------------------- 1 | #11.1.3.11 判断主从是否完全一致 2 | dbsize 3 | 4 | 查看key 的数目 5 | 6 | debug digest 7 | 8 | 对整个数据库的数据，产生一个摘要，可用于验证两个redis数据库数据是否一致 9 | 127.0.0.1:6379> debug digest 10 | 7164ae8b6730c8bcade46532e5e4a8015d4cccfb 11 | 127.0.0.1:6379> debug digest 12 | 7164ae8b6730c8bcade46532e5e4a8015d4cccfb 13 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-resetst.md: -------------------------------------------------------------------------------- 1 | #11.1.3.8 重置该sentinel 2 | sentinel reset myredis 3 | 重置操作清除该sentinel的所保存的所有状态信息，并进行一次重新的发现过程。 4 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-startstop.md: -------------------------------------------------------------------------------- 1 | #11.1.3.2 启停redis 2 | supervisorctl -c /redis/conf/redis-supervisord.conf start redis 3 | supervisorctl -c /redis/conf/redis-supervisord.conf stop redis 4 | supervisorctl -c /redis/conf/redis-supervisord.conf restart redis 5 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-startstopsentinel.md: -------------------------------------------------------------------------------- 1 | #11.1.3.4 启停sentinel 2 | supervisorctl -c /redis/conf/redis-supervisord.conf start redis-sentinel 3 | supervisorctl -c /redis/conf/redis-supervisord.conf stop redis-sentinel 4 | supervisorctl -c /redis/conf/redis-supervisord.conf restart redis-sentinel 5 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-ststate.md: -------------------------------------------------------------------------------- 1 | #11.1.3.5 查看sentinel状态 2 | redis-cli -p 26379 info 3 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation-subevent.md: -------------------------------------------------------------------------------- 1 | #11.1.3.12 接收所有事件信息 2 | 127.0.0.1:26379> PSUBSCRIBE * 3 | 4 | 注意这是在sentinel上监控所有的频道信息，查看的是切换前后发生的消息。 5 | 6 | 还有一个\_\_sentinel\_\_:hello的频道，这个频道是在redis实例上的，用途是sentinel之间发现对方的，别无它用。在redis实例上可以通过monitor或者订阅此频道看到这个消息。 7 | -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/operation.md: -------------------------------------------------------------------------------- 1 | #11.1.3 维护操作 -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/other1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/other1.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/other2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/other2.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/other3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/other3.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/other4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/other4.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/other5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/HAClusterArchPractice/ms/other5.png -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/others.md: -------------------------------------------------------------------------------- 1 | #11.1.5 其他问题 -------------------------------------------------------------------------------- /HAClusterArchPractice/ms/readonly.md: -------------------------------------------------------------------------------- 1 | #11.1.5.1 只读性 2 | 主从复制架构下，默认Slave是只读的，如果写入则会报错： 3 | 4 | 127.0.0.1:6379> set foo bar 5 | (error) READONLY You can't write against a read only slave. 6 | 7 | 注意这个行为是可以修改的，虽然这样的修改没有意义： 8 | 9 | 127.0.0.1:6379> CONFIG SET slave-read-only no 10 | OK 11 | 127.0.0.1:6379> set foo bar 12 | OK 13 | 14 | -------------------------------------------------------------------------------- /HAClusterBrief/README.md: -------------------------------------------------------------------------------- 1 | #10. 简述 2 | 3 | -------------------------------------------------------------------------------- /HAClusterBrief/comparison.md: -------------------------------------------------------------------------------- 1 | #10.4 适用场景对比列表 2 | | | | | | | 3 | |-----------------|--------|-------|-------|----------| 4 | | --- | 动态扩容能力 | 系统复杂度 | 开发复杂度 | 运维复杂度 | 5 | | 主从复制+Sentinel | No | 简单 | 简单 | 简单 | 6 | | Twemproxy | No | 简单 | 简单 | 稍微复杂 | 7 | | 3.0 Cluster | Yes | 简单 | 简单 | 复杂 | 8 | | Codis | Yes | 复杂 | 简单 | 复杂 | 9 | | 应用层面presharding | Yes | 复杂 | 复杂 | 视开发的水平而定 | -------------------------------------------------------------------------------- /HAClusterBrief/concept.md: -------------------------------------------------------------------------------- 1 | #10.1 概念 2 | 3 | 在本文档中，高可用主要指的是解决尽可能在不丢失数据的前提下不间断服务问题，由于redis是异步复制，因此不保证数据完全不丢失，在这个场景下并不实现动态横向扩容，只能进行纵向扩容，你只要加内存，启动redis，设置maxmemory即可。而分片（Sharding）主要指的是解决在线动态横向扩容缩容问题，当然为了稳定也进行高可用部署配置，即包含成对的主从关系。 -------------------------------------------------------------------------------- /HAClusterBrief/scenario.md: -------------------------------------------------------------------------------- 1 | #10.2 高可用主要场景和对应思路 2 | 适用于redis非重度用户，内存占用不大，总体内存大小的增长趋势可预估，有一定停机时间的系统——纵向扩容即可满足，可以对全库进行主从复制即满足需求而不需要做分片，一般针对单个小型项目的cache 等场景。一般采用一主多从的sentinel方案进行部署。 -------------------------------------------------------------------------------- /HAClusterBrief/sharding.md: -------------------------------------------------------------------------------- 1 | #10.3 分片主要场景和对应思路 2 | 分片是为了应对业务增长带来的数据增长，需要对动态横向扩容有一定要求时采用。对于一般的分片采用一致性哈希，它极大的优化机器增删时带来的哈希目标漂移问题。同时对于Hash目标漂移时产生的严重的数据倾斜，可以利用虚拟节点来优化。基本上，物理节点有了一定规模后，只要不是同时挂多个节点，或者同时扩容多个节点，数据分片不会有太大的扰动。穿透过Cache的请求后端存储可以抗住即可。 3 | 4 | 稍微复杂的方案是可以使用“预分片（Pre-Sharding)”的方案，也称为按“桶”进行数据划分，即分配一个相当大的集合，对Key哈希的结果落在这个集合中，集合的每个元素又与具体的物理节点存在多对一的路由映射关系，这张路由表由一个配置中心进行维护。其实，一致性哈希中的虚拟节点，实际上也可以归类到Pre-Sharding方案中。换句话说，只要是key经过两次哈希，第一次Hash到虚拟节点，第二次Hash到物理节点，都可以算作Pre-Sharding。只不过区别在于，一致性哈希的第二次Hash其路由表是按照算法固定的，而分桶的第二次Hash其路由表是第三方可配的。 5 | -------------------------------------------------------------------------------- /IndependentFunc/README.md: -------------------------------------------------------------------------------- 1 | # 3. 专题功能 -------------------------------------------------------------------------------- /IndependentFunc/pipeline.md: -------------------------------------------------------------------------------- 1 | #3.3 流水线 2 | 利用流水线（pipeline）的方式从client打包多条命令一起发出，不需要等待单条命令的响应返回，而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端： 3 | 4 | cat data.txt | redis-cli –pipe 5 | 6 | 在选择开源redis开发库时需要着重注意是否支持pipeline，常见的jedis可以支持。 7 | 8 | 在部署架构是网络多跳的时候需要注意使用pipeline提高处理效率。 9 | -------------------------------------------------------------------------------- /IndependentFunc/pubsub.md: -------------------------------------------------------------------------------- 1 | #3.4 发布订阅 2 | redis作为一个pub/sub server，在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型，redis将消息类型称为频道(channel)。当发布者通过publish命令向redis server发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个 channel,也可以向多个channel发送消息。 3 | 4 | 终端A： 5 | 127.0.0.1:6379> subscribe comments 6 | Reading messages... (press Ctrl-C to quit) 7 | 1) "subscribe" 8 | 2) "comments" 9 | 3) (integer) 1 10 | 终端B: 11 | 127.0.0.1:6379> subscribe comments 12 | Reading messages... (press Ctrl-C to quit) 13 | 1) "subscribe" 14 | 2) "comments" 15 | 3) (integer) 1 16 | 终端C： 17 | 127.0.0.1:6379> publish comments good! 18 | (integer) 2 19 | 终端A: 20 | 127.0.0.1:6379> subscribe comments 21 | Reading messages... (press Ctrl-C to quit) 22 | 1) "subscribe" 23 | 2) "comments" 24 | 3) (integer) 1 25 | 1) "message" 26 | 2) "comments" 27 | 3) "good!" 28 | 终端B： 29 | 127.0.0.1:6379> subscribe comments 30 | Reading messages... (press Ctrl-C to quit) 31 | 1) "subscribe" 32 | 2) "comments" 33 | 3) (integer) 1 34 | 1) "message" 35 | 2) "comments" 36 | 3) "good!" 37 | 38 | 可以使用psubscribe通过通配符进行多个channel的订阅 39 | -------------------------------------------------------------------------------- /IndependentFunc/sort.md: -------------------------------------------------------------------------------- 1 | #3.1 排序 2 | redis支持对list，set和sorted set元素的排序。排序命令是sort 完整的命令格式如下： 3 | 4 | SORT key [BY pattern] [LIMIT start count] [GET pattern] [ASC|DESC] [ALPHA] [STORE dstkey] 5 | 6 | 复杂度为O(N+M*log(M))。(N是集合大小，M 为返回元素的数量) 7 | 8 | 说明： 9 | 1. [ASC|DESC] [ALPHA]: sort默认的排序方式（asc）是从小到大排的,当然也可以按照逆序或者按字符顺序排。 10 | 2. [BY pattern] : 除了可以按集合元素自身值排序外，还可以将集合元素内容按照给定pattern组合成新的key，并按照新key中对应的内容进行排序。例如： 11 | 3. 127.0.0.1:6379sort watch:leto by severtity:* desc 12 | 4. [GET pattern]：可以通过get选项去获取指定pattern作为新key对应的值，get选项可以有多个。例如：127.0.0.1:6379sort watch:leto by severtity:* get severtity:*。 对于Hash的引用，采用->，例如：sort watch:leto get # get bug:*->priority。 13 | 5. [LIMIT start count] 限定返回结果的数量。 14 | 6. [STORE dstkey] 把排序结果缓存起来 15 | 16 | 17 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/IndependentFunc/sort1.png) 18 | 19 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/IndependentFunc/sort2.png) 20 | 21 | -------------------------------------------------------------------------------- /IndependentFunc/sort1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/IndependentFunc/sort1.png -------------------------------------------------------------------------------- /IndependentFunc/sort2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/IndependentFunc/sort2.png -------------------------------------------------------------------------------- /IndependentFunc/transection.md: -------------------------------------------------------------------------------- 1 | #3.2 事务 2 | 用Multi(Start Transaction)、Exec(Commit)、Discard(Rollback)实现。 在事务提交前，不会执行任何指令，只会把它们存到一个队列里，不影响其他客户端的操作。在事务提交时，批量执行所有指令。 3 | 一般情况下redis在接受到一个client发来的命令后会立即处理并返回处理结果，但是当一个client在一个连接中发出multi命令后，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到exec命令后，redis会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给client.然后此连接就结束事务上下文。 4 | 5 | Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。 6 | 7 | 使用discard命令来取消一个事务。 8 | 9 | 注意：redis只能保证事务的每个命令连续执行（因为是单线程架构，在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的，也因此就不存在"事务内的查询要看到事务里的更新，在事务外查询不能看到"这个让人万分头痛的问题），但是如果事务中的一个命令失败了，并不回滚其他命令。另外，一个十分罕见的问题是当事务的执行过程中，如果redis意外的挂了。只有部分命令执行了，后面的也就被丢弃了。注意，如果是笔误，语法出现错误，则整个事务都无法执行。 10 | 11 | 一个简单案例表明出错也不会回滚： 12 | 13 | 127.0.0.1:6379> del q1 14 | (integer) 0 15 | 127.0.0.1:6379> exists q1 16 | (integer) 0 17 | 127.0.0.1:6379> multi 18 | OK 19 | 127.0.0.1:6379> rpush q1 bar 20 | QUEUED 21 | 127.0.0.1:6379> scard q1 22 | QUEUED 23 | 127.0.0.1:6379> exec 24 | 1) (integer) 1 25 | 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 26 | 127.0.0.1:6379> exists q1 27 | (integer) 1 28 | 29 | 30 | 当然如果我们使用的append-only file方式持久化，redis会用单个write操作写入整个事务内容。即是是这种方式还是有可能只部分写入了事务到磁盘。发生部分写入事务的情况下，redis重启时会检测到这种情况，然后失败退出。可以使用redis-check-aof工具进行修复，修复会删除部分写入的事务内容。修复完后就能够重新启动了。 31 | -------------------------------------------------------------------------------- /Intro/README.md: -------------------------------------------------------------------------------- 1 | # 1. 简述 2 | 3 | Redis为一个运行在内存中的数据结构服务器（data structures server）。Redis使用的是单进程（除持久化时），所以在配置时，一个实例只会用到一个CPU。本手册分为三部分，第一部分从开发角度介绍了redis开发中使用API、场景和生产设计规范最佳实践，第二部分从运维角度介绍了如何运维redis，其间的常见操作和最佳实践等,第三部分是从高可用和集群方面介绍了redis相关的集群架构、搭建和测试。 4 | -------------------------------------------------------------------------------- /Migration/README.md: -------------------------------------------------------------------------------- 1 | # 7. 数据迁移 -------------------------------------------------------------------------------- /Migration/move.md: -------------------------------------------------------------------------------- 1 | #4.1 将key从当前数据库移动到指定数据库 2 | move key db-index 3 | 返回1成功。0 如果key不存在，或者已经在指定数据库中 4 | -------------------------------------------------------------------------------- /Monitor/monitor.md: -------------------------------------------------------------------------------- 1 | | 监控类型 | 监控内容 | 监控方法 | 告警级别 | 备注 | 2 | |---------- |---------------------------------------------------------------------------- |---------- |--------------------------------------------------- |------------------------------------ | 3 | | 进程监控 | redis-server | 进程探测 | 1-正常，0-主要告警 | | | 4 | | 进程监控 | redis-sentinel | 进程探测 | 1-正常，0-次要告警 | 压制两次 | 5 | | 端口监控 | 6679 | telnet | 可连接-正常，无法连接-主要告警 | 与redis-server进程监控二选一即可 | 6 | | 端口监控 | 26679 | telnet | 可连接-正常，无法连接-次要告警 | 与redis-sentinel进程监控二选一即可 | 7 | | 内存监控 | redis-cliinfo Memory | grep used_memory_human | cut -d':' -f2 | sed 's/G//' | 数值判断 | 根据max内存的80%数值为次要告警，90%数值为主要告警 | | 8 | | 日志监控 | /redis/log/redis-sentinel.log | 关键词 | odown、failover为主要告警 | | -------------------------------------------------------------------------------- /Operation/README.md: -------------------------------------------------------------------------------- 1 | # 6. 常见运维操作 -------------------------------------------------------------------------------- /Operation/auth.md: -------------------------------------------------------------------------------- 1 | #3.10 验证密码 2 | auth passw0rd 3 | -------------------------------------------------------------------------------- /Operation/bulk.md: -------------------------------------------------------------------------------- 1 | #3.4 批量执行操作 2 | 使用telnet也可以连接redis-server。并且在脚本中使用nc命令进行redis操作也是很有效的： 3 | 4 | gnuhpc@gnuhpc:~$ (echo -en "ping\r\nset key abc\r\nget key\r\n";sleep 1) | nc 127.0.0.1 6379 5 | +PONG 6 | +OK 7 | $3 8 | abc 9 | 10 | 另一个方式是使用pipeline： 11 | 12 | 在一个脚本中批量执行多个写入操作: 13 | 先把插入操作放入操作文本insert.dat： 14 | set a b 15 | set 1 2 16 | set h w 17 | set f u 18 | 然后执行命令:cat insert.bat | ./redis-cli --pipe，或者如下脚本： 19 | #!/bin/sh 20 | host=$1 21 | port=$； 22 | password=$3 23 | cat insert.dat | ./redis-cli -h $host -p $port -a $password --pipe 24 | -------------------------------------------------------------------------------- /Operation/config.md: -------------------------------------------------------------------------------- 1 | #3.3 查看和修改配置 2 | 查看： 3 | 4 | config get ：获取服务器配置信息。 5 | redis 127.0.0.1:6379> config get dir 6 | config get *：查看所有配置 7 | 8 | 修改： 9 | 10 | 临时设置：config set 11 | 永久设置：config rewrite，将目前服务器的参数配置写入redis conf. 12 | -------------------------------------------------------------------------------- /Operation/flush.md: -------------------------------------------------------------------------------- 1 | 3.6 清空数据库 2 | 3 | flushdb 4 | 删除当前选择数据库中的所有 key。生产上已经禁止。 5 | 6 | flushall 7 | 删除所有的数据库。生产上已经禁止。 8 | -------------------------------------------------------------------------------- /Operation/lua.md: -------------------------------------------------------------------------------- 1 | #3.8 执行lua脚本 2 | 3 | --eval 4 | 例如： 5 | redis-cli --eval myscript.lua key1 key2 , arg1 arg2 arg3 6 | -------------------------------------------------------------------------------- /Operation/password.md: -------------------------------------------------------------------------------- 1 | #3.9 设置密码 2 | config set requirepass [passw0rd] 3 | -------------------------------------------------------------------------------- /Operation/persistence-backup/README.md: -------------------------------------------------------------------------------- 1 | # 6.13 持久化与备份恢复 -------------------------------------------------------------------------------- /Operation/persistence-backup/aof.md: -------------------------------------------------------------------------------- 1 | #3.13.2 AOF相关操作 2 | BGREWRITEAOF 3 | 在后台执行一个 AOF文件重写操作 4 | 5 | 6 | 动态关闭AOF： 7 | 8 | redis-cli config set appendonly no 9 | 动态打开AOF： 10 | 11 | redis-cli config set appendonly yes 12 | 永久关闭AOF： 13 | 14 | sed -e '/appendonly/ s/^#*/#/' -i /etc/redis/redis.conf （默认是关闭的） 15 | 永久打开AOF： 16 | 17 | 将appendonly yes设置在redis.conf中 18 | 19 | -------------------------------------------------------------------------------- /Operation/persistence-backup/backup.md: -------------------------------------------------------------------------------- 1 | #3.13.3 备份 2 | 对于RDB和AOF，都是直接拷贝文件即可，可以设定crontab进行定时备份： 3 | cp /var/lib/redis/dump.rdb /somewhere/safe/dump.$(date +%Y%m%d%H%M).rdb 4 | -------------------------------------------------------------------------------- /Operation/persistence-backup/rdb.md: -------------------------------------------------------------------------------- 1 | #3.13.1 RDB相关操作 2 | BGSAVE：后台子进程进行RDB持久化 3 | SAVE：主进程进行RDB，生产环境千万别用，服务器将无法响应任何操作。 4 | LASTSAVE： 返回上一次成功SAVE的Unix时间 5 | 6 | 7 | 8 | 动态关闭RDB： 9 | 10 | redis-cli config set save "" 11 | 12 | 动态设置RDB： 13 | 14 | redis-cli config set save "900 1" 15 | 永久关闭RDB： 16 | 17 | sed -e '/save/ s/^#*/#/' -i /etc/redis/redis.conf 18 | 永久设置RDB： 19 | 20 | 在redis.conf中设置save选项 21 | 22 | 查看RDB是否打开： 23 | 24 | redis-cli config get save 25 | 空的即是关闭，有数字的都是打开的。 26 | 27 | -------------------------------------------------------------------------------- /Operation/persistence-backup/recovery.md: -------------------------------------------------------------------------------- 1 | #3.13.4 恢复 2 | 如果只使用了RDB，则首先将redis-server停掉，删除dump.rdb，最后将备份的dump.rdb文件拷贝回data目录并修改相关属主保证其属主和redis-server启动用户一致，然后启动redis-server。 3 | 4 | 如果是RDB+AOF的持久化，只需要将aof文件放入data目录，启动redis-server，查看是否恢复，如无法恢复则应该将aof关闭后重启，redis就会从rdb进行恢复了，随后调用命令BGREWRITEAOF进行AOF文件写入，在info的aof_rewrite_in_progress为0后一个新的aof文件就生成了，此时再将配置文件的aof打开，再次重启redis-server就可以恢复了。注意先不要将dump.rdb放入data目录，否则会因为aof文件万一不可用，则rdb也不会被恢复进内存，此时如果有新的请求进来后则原先的rdb文件被重写。 5 | 6 | 7 | 如果只配置了AOF，重启时加载AOF文件恢复数据。 8 | 9 | 10 | 恢复速度参见新浪的测试结果： 11 | ![](https://raw.githubusercontent.com/gnuhpc/All-About-Redis/master/Operation/persistence-backup/recovery.png) 12 | 13 | 这个结果是可信的，在一台SSD、4个CPU的虚拟机上测试为28.3G/s. 14 | 15 | 16 | 检查修复AOF文件： 17 | 18 | redis-check-aof data/appendonly.aof 19 | 20 | -------------------------------------------------------------------------------- /Operation/persistence-backup/recovery.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/Operation/persistence-backup/recovery.png -------------------------------------------------------------------------------- /Operation/redis-cli.md: -------------------------------------------------------------------------------- 1 | #3.12 Redis-cli命令行其他操作 2 | 3 | #### 1. echo ：在命令行打印一些内容 #### 4 | redis 127.0.0.1:6379> echo HongWan 5 | "HongWan" 6 | 7 | #### 2. quit ：退出连接。 #### 8 | redis 127.0.0.1:6379> quit 9 | 10 | #### 3. -x选项从标准输入（stdin）读取最后一个参数。 比如从管道中读取输入： #### 11 | echo -en "chen.qun" | redis-cli -x set name 12 | 13 | #### 4. -r -i #### 14 | -r 选项重复执行一个命令指定的次数。 15 | -i 设置命令执行的间隔。 16 | 比如查看redis每秒执行的commands（qps） 17 | redis-cli -r 100 -i 1 info stats | grep instantaneous_ops_per_sec 18 | 这个选项在编写一些脚本时非常有用 19 | 20 | #### 5. -c：开启reidis cluster模式，连接redis cluster节点时候使用。 #### 21 | 22 | #### 6. --rdb：获取指定redis实例的rdb文件,保存到本地。 #### 23 | redis-cli -h 192.168.44.16 -p 6379 --rdb 6379.rdb 24 | 25 | #### 7. --slave #### 26 | 模拟slave从master上接收到的commands。slave上接收到的commands都是update操作，记录数据的更新行为。 27 | 28 | 29 | #### 8. --pipe #### 30 | 这个一个非常有用的参数。发送原始的redis protocl格式数据到服务器端执行。比如下面的形式的数据（linux服务器上需要用unix2dos转化成dos文件）。 31 | linux下默认的换行是\n,windows系统的换行符是\r\n，redis使用的是\r\n. 32 | echo -en '*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n' | redis-cli --pipe 33 | 34 | 35 | ###9. -a ### 36 | 如果开启了requirepass，那么你如果希望调用或者自己编写一些外部脚本通过redis-cli进行操作或者监控redis，那么这个选项可以让你不用再手动输入auth。这个选项很普遍，但是往往被人忽视。 37 | 38 | -------------------------------------------------------------------------------- /Operation/rename-command.md: -------------------------------------------------------------------------------- 1 | #3.7 重命名命令 2 | rename-command 3 | 例如：rename-command FLUSHALL ""。必须重启。 4 | -------------------------------------------------------------------------------- /Operation/select.md: -------------------------------------------------------------------------------- 1 | #3.5 选择数据库 2 | select db-index 3 | 默认连接的数据库所有是0,默认数据库数是16个。返回1表示成功，0失败 4 | -------------------------------------------------------------------------------- /Operation/start.md: -------------------------------------------------------------------------------- 1 | #3.1 启动 2 | ## 3.1.1 启动redis ## 3 | $ redis-server redis.conf 4 | 5 | 常见选项： 6 | ./redis-server (run the server with default conf) 7 | ./redis-server /etc/redis/6379.conf 8 | ./redis-server --port 7777 9 | ./redis-server --port 7777 --slaveof 127.0.0.1 8888 10 | ./redis-server /etc/myredis.conf --loglevel verbose 11 | 12 | ## 3.1.2 启动redis-sentinel ## 13 | 14 | ./redis-server /etc/sentinel.conf –sentinel 15 | ./redis-sentinel /etc/sentinel.conf 16 | 17 | 部署后可以使用sstart对redis 和sentinel进行拉起，使用sctl进行supervisorctl的控制。（两个alias） 18 | -------------------------------------------------------------------------------- /Operation/stop.md: -------------------------------------------------------------------------------- 1 | #3.2 停止 2 | 3 | redis-cli shutdown 4 | 5 | sentinel方法一样，只是需要执行sentinel的连接端口 6 | > 7 | > 注意：正确关闭服务器方式是redis-cli shutdown 或者 kill，都会graceful shutdown，保证写RDB文件以及将AOF文件fsync到磁盘，不会丢失数据。 如果是粗暴的Ctrl+C，或者kill -9 就可能丢失。如果有配置save，还希望在shutdown时进行RDB写入，那么请使用shutdown save命令。 8 | > -------------------------------------------------------------------------------- /Problem/README.md: -------------------------------------------------------------------------------- 1 | # 8. 数据迁移 -------------------------------------------------------------------------------- /Problem/general/README.md: -------------------------------------------------------------------------------- 1 | # 8.1 一般处理流程 -------------------------------------------------------------------------------- /Problem/general/checkfix-aof.md: -------------------------------------------------------------------------------- 1 | #6.1.8 检查修复AOF文件 2 | redis-check-aof data/appendonly.aof 3 | -------------------------------------------------------------------------------- /Problem/general/client.md: -------------------------------------------------------------------------------- 1 | #6.1.6 查看客户端 2 | client list 3 | 列出所有连接 4 | 5 | client kill 6 | 杀死某个连接， 例如`CLIENT KILL 127.0.0.1:43501` 7 | 8 | client getname # 9 | 获取连接的名称 默认nil 10 | 11 | client setname "名称" 12 | 设置连接名称,便于调试 13 | -------------------------------------------------------------------------------- /Problem/general/latency-detect.md: -------------------------------------------------------------------------------- 1 | #6.1.2 探测服务延迟 2 | redis-cli --latency 3 | 显示的单位是milliseconds，作为参考，千兆网一跳一般延迟为0.16ms左右 -------------------------------------------------------------------------------- /Problem/general/log.md: -------------------------------------------------------------------------------- 1 | #6.1.7 查看日志 2 | 日志位置在/redis/log下，redis.log为redis主日志，sentinel.log为sentinel监控日志。 3 | -------------------------------------------------------------------------------- /Problem/general/monitor.md: -------------------------------------------------------------------------------- 1 | 6.1.3 监控正在请求执行的命令 2 | 在cli下执行monitor，**生产环境慎用。** 3 | -------------------------------------------------------------------------------- /Problem/general/redis-stat.md: -------------------------------------------------------------------------------- 1 | #6.1.9 可视化监控 2 | 3 | [redis-stat](https://github.com/junegunn/redis-stat) 是一个简单易用的 redis 监控工具。它利用 redis 的 info 命令收集数据并展示到 web 页面。可以通过 ```gem install redis-stat``` 命令完成安装，或者使用 [docker ](https://github.com/morfeo8marc/redis-stat-docker) 安装。redis-stat监控效果图： 4 | 5 | ![](../../images/redis-stat.png) 6 | -------------------------------------------------------------------------------- /Problem/general/service-detect.md: -------------------------------------------------------------------------------- 1 | #6.1.1 探测服务是否可用 2 | 127.0.0.1:6379> ping 3 | 返回PONG说明正常 4 | -------------------------------------------------------------------------------- /Problem/general/slowlog.md: -------------------------------------------------------------------------------- 1 | #6.1.5 获取慢查询 2 | SLOWLOG GET 10 3 | 结果为查询ID、发生时间、运行时长和原命令 4 | 默认10毫秒，默认只保留最后的128条。单线程的模型下，一个请求占掉10毫秒是件大事情，注意设置和显示的单位为微秒，注意这个时间是不包含网络延迟的。 5 | 6 | slowlog get 7 | 获取慢查询日志 8 | 9 | slowlog len 10 | 获取慢查询日志条数 11 | 12 | slowlog reset 13 | 清空慢查询 14 | -------------------------------------------------------------------------------- /Problem/latency/README.md: -------------------------------------------------------------------------------- 1 | #6.2 并发延迟检查 2 | top看到单个CPU 100%时，就是垂直扩展的时候了。如果需要让CPU使用率最大化，可以配置Redis实例数对应CPU数, Redis实例数对应端口数(8核Cpu, 8个实例, 8个端口), 以提高并发。单机测试时, 单条数据在200字节, 测试的结果为8~9万tps。（未实测）。 3 | 另外，对于命令的复杂度一定要关注。 4 | -------------------------------------------------------------------------------- /Problem/latency/commands.md: -------------------------------------------------------------------------------- 1 | #6.2.6 检查命令执行情况 2 | INFO commandstats 3 | 4 | 查看命令执行了多少次，执行命令所耗费的毫秒数(每个命令的总时间和平均时间) 5 | -------------------------------------------------------------------------------- /Problem/latency/cpu.md: -------------------------------------------------------------------------------- 1 | #6.2.1 检查CPU情况 2 | mpstat -P ALL 1 3 | -------------------------------------------------------------------------------- /Problem/latency/network.md: -------------------------------------------------------------------------------- 1 | #6.2.2 检查网络情况 2 | 可以在系统不繁忙或者临时下线前检测客户端和server或者proxy 的带宽： 3 | 4 | 1)使用 iperf -s 命令将 Iperf 启动为 server 模式: 5 | 6 | iperf –s 7 | ———————————————————— 8 | Server listening on TCP port 5001 9 | TCP window size: 8.00 KByte (default) 10 | ———————————————————— 11 | 2)启动客户端，向IP为10.230.48.65的主机发出TCP测试，并每2秒返回一次测试结果，以Mbytes/sec为单位显示测试结果： 12 | 13 | iperf -c 10.230.48.65 -f M -i 2 14 | -------------------------------------------------------------------------------- /Problem/latency/overall-check.md: -------------------------------------------------------------------------------- 1 | #6.2.3 检查系统情况 2 | 着重检查探测服务延迟、 监控正在请求执行的命令、获取慢查询 3 | -------------------------------------------------------------------------------- /Problem/latency/persistence-check.md: -------------------------------------------------------------------------------- 1 | #6.2.5 检查持久化 2 | RDB的时间：`latest_fork_usec:936 ` 上次导出rdb快照,持久化花费，微秒。 3 | 检查是否有人使用了SAVE。 4 | -------------------------------------------------------------------------------- /Problem/latency/total-commands.md: -------------------------------------------------------------------------------- 1 | #6.2.4 检查连接数 2 | 查看info里面的total_connections_received，如果该值不断升高，则需要修改应用，采用连接池方式进行，因为频繁关闭再创建连接redis的开销很大。 3 | -------------------------------------------------------------------------------- /Problem/memory/README.md: -------------------------------------------------------------------------------- 1 | # 8.3 内存检查 -------------------------------------------------------------------------------- /Problem/memory/debug-key.md: -------------------------------------------------------------------------------- 1 | #8.3.8 查看key内部结构和编码等信息 2 | debug object 3 | 4 | 查看一个key内部信息，比如refcount、encoding、serializedlength等，结果如下 5 | Value at:0x7f21b9479850 refcount:1 encoding:raw serializedlength:6 lru:8462202 lru_seconds_idle:215 6 | -------------------------------------------------------------------------------- /Problem/memory/faina.md: -------------------------------------------------------------------------------- 1 | #8.3.5 query在线分析 2 | redis-cli MONITOR | head -n 5000 | ./redis-faina.py 3 | -------------------------------------------------------------------------------- /Problem/memory/info.md: -------------------------------------------------------------------------------- 1 | #8.3.3 info查看内存 2 | `used_memory:859192 `数据结构的空间 3 | `used_memory_rss:7634944 `实占空间 4 | `mem_fragmentation_ratio:8.89 `前2者的比例,1.N为佳,如果此值过大,说明redis的内存的碎片化严重,可以导出再导入一次. 5 | -------------------------------------------------------------------------------- /Problem/memory/rdb-tool.md: -------------------------------------------------------------------------------- 1 | #8.3.4 dump.rdb文件成生内存报告（rdb-tool） 2 | # rdb -c memory ./dump.rdb > redis_memory_report.csv 3 | # sort -t, -k4nr redis_memory_report.csv 4 | -------------------------------------------------------------------------------- /Problem/memory/rss.md: -------------------------------------------------------------------------------- 1 | #8.3.9 Rss增加，内存碎片增加 2 | 此时可以选择时间进行redis服务器的重新启动，并且注意在rss突然降低观察是否swap被使用，以确定并非是因为swap而导致的rss降低。 3 | 4 | 一个典型的例子是：http://grokbase.com/t/gg/redis-db/14ag5n9qhv/redis-memory-fragmentation-ratio-reached-5000 5 | 6 | 7 | -------------------------------------------------------------------------------- /Problem/memory/sample.md: -------------------------------------------------------------------------------- 1 | #8.3.6 内存抽样分析 2 | /redis/script/redis-sampler.rb 127.0.0.1 6379 0 10000 3 | /redis/script/redis-audit.rb 127.0.0.1 6379 0 10000 4 | -------------------------------------------------------------------------------- /Problem/memory/scan-bigkey.md: -------------------------------------------------------------------------------- 1 | #8.3.7 统计生产上比较大的key 2 | ./redis-cli --bigkeys 3 | 对redis中的key进行采样，寻找较大的keys。是用的是scan方式，不用担心会阻塞redis很长时间不能处理其他的请求。执行的结果可以用于分析redis的内存的只用状态，每种类型key的平均大小。 4 | -------------------------------------------------------------------------------- /Problem/memory/swap.md: -------------------------------------------------------------------------------- 1 | #8.3.2 系统swap内存查看 2 | 3 | #!/bin/bash 4 | # Get current swap usage for all running processes 5 | # Erik Ljungstrom 27/05/2011 6 | # Modified by Mikko Rantalainen 2012-08-09 7 | # Pipe the output to "sort -nk3" to get sorted output 8 | # Modified by Marc Methot 2014-09-18 9 | # removed the need for sudo 10 | 11 | SUM=0 12 | OVERALL=0 13 | for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` 14 | do 15 | PID=`echo $DIR | cut -d / -f 3` 16 | PROGNAME=`ps -p $PID -o comm --no-headers` 17 | for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'` 18 | do 19 | let SUM=$SUM+$SWAP 20 | done 21 | if (( $SUM > 0 )); then 22 | echo "PID=$PID swapped $SUM KB ($PROGNAME)" 23 | fi 24 | let OVERALL=$OVERALL+$SUM 25 | SUM=0 26 | done 27 | echo "Overall swap used: $OVERALL KB" 28 | 29 | 30 | -------------------------------------------------------------------------------- /Problem/memory/system-memory.md: -------------------------------------------------------------------------------- 1 | #8.3.1 系统内存查看 2 | script/下的memstat.sh或者ps_mem.py都可以查看系统的内存情况，两个工具都需要root权限。 3 | -------------------------------------------------------------------------------- /ProdEnvDeploy/README.md: -------------------------------------------------------------------------------- 1 | # 5. 上线部署规划 -------------------------------------------------------------------------------- /ProdEnvDeploy/conf.md: -------------------------------------------------------------------------------- 1 | #5.6 具体设置参数 2 | 详见我行自制安装包conf目录中的各个配置文件和上线前检查表格。 3 | 4 | redis参数设置技巧列表： 5 | 1. Daemonize 6 | 这个参数在使用supervisord这种进程管理工具时一定要设置为no，否则无法使用这些工具将redis启动。 7 | 8 | 2. Dir 9 | RDB的位置，一定要事先创建好，并且启动redis 的用户对此目录要有读写权限。 10 | 3. Include 11 | 如果是多实例的话可以将公共的设置放在一个conf文件中，然后引用即可： 12 | include /redis/conf/redis-common.conf 13 | -------------------------------------------------------------------------------- /ProdEnvDeploy/memory.md: -------------------------------------------------------------------------------- 1 | #5.1 内存、CPU规划 2 | 一定要设置最大内存maxmemory参数，否则物理内存用爆了就会大量使用Swap，写RDB文件时的速度很慢。注意这个参数指的是info中的used_memory，在一些不利于jmalloc的时候，内存碎片会很大。 3 | 4 | 多留55%内存是最安全的。重写AOF文件和RDB文件的进程(即使不做持久化，复制到Slave的时候也要写RDB)会fork出一条新进程来，采用了操作系统的Copy-On-Write策略(子进程与父进程共享Page。如果父进程的Page-每页4K有修改，父进程自己创建那个Page的副本，不会影响到子进程)。 5 | 6 | 另外，需要考虑内存碎片，假设碎片为1.2，则如果机器为64G，那么64*45%/1.2 = 24G作为maxmemory是比较安全的规划。 7 | 8 | 留意Console打出来的报告，如"RDB: 1215 MB of memory used by copy-on-write"。在系统极度繁忙时，如果父进程的所有Page在子进程写RDB过程中都被修改过了，就需要两倍内存。 9 | 10 | 按照Redis启动时的提醒，设置 11 | 12 | echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf 13 | 14 | 使得fork()一条10G的进程时，因为COW策略而不一定需要有10G的free memory。 15 | 16 | 另外，记得关闭THP，这个默认的Linux内存页面大小分配策略会导致RDB时出现巨大的latency和巨大的内存占用。关闭方法为： 17 | 18 | echo never > /sys/kernel/mm/transparent_hugepage/enabled 19 | echo never > /sys/kernel/mm/transparent_hugepage/defrag 20 | 21 | 22 | 当最大内存到达时，按照配置的Policy进行处理， 默认策略为volatile-lru，对设置了expire time的key进行LRU清除(不是按实际expire time)。如果沒有数据设置了expire time或者policy为noeviction，则直接报错，但此时系统仍支持get之类的读操作。 另外还有几种policy，比如volatile-ttl按最接近expire time的，allkeys-lru对所有key都做LRU。注意在一般的缓存系统中，如果没有设置超时时间，则lru的策略需要设置为allkeys-lru，并且应用需要做好未命中的异常处理。特殊的，当redis当做DB时，请使用noneviction策略，但是需要对系统内存监控加强粒度。 23 | 24 | CPU不求核数多，但求主频高，Cache大，因为redis主处理模式是单进程的。同时避免使用虚拟机。 25 | 26 | -------------------------------------------------------------------------------- /ProdEnvDeploy/multi-instance.md: -------------------------------------------------------------------------------- 1 | #5.5 多实例配置 2 | 如果一台机器上防止多个redis实例，为了防止上下文切换导致的开销，可以采用taskset。taskset是LINUX提供的一个命令(ubuntu系统可能需要自行安装，schedutils package)。他可以让某个程序运行在某个（或）某些CPU上。 3 | 4 | 1）显示进程运行的CPU （6137为redis-server的进程号） 5 | 6 | [redis@hadoop1 ~]$ taskset -p 6137 7 | pid 6137's current affinity mask: f 8 | 显示结果的f实际上是二进制4个低位均为1的bitmask，每一个1对应于1个CPU，表示该进程在4个CPU上运行 9 | 10 | 2）指定进程运行在某个特定的CPU上 11 | 12 | [redis@hadoop1 ~]$ taskset -pc 3 6137 13 | pid 6137's current affinity list: 0-3 14 | pid 6137's new affinity list: 3 15 | 注：3表示CPU将只会运行在第4个CPU上（从0开始计数）。 16 | 17 | 3）进程启动时指定CPU 18 | 19 | taskset -c 1 ./redis-server ../redis.conf 20 | 21 | 参数：OPTIONS 22 | -p, --pid 23 | operate on an existing PID and not launch a new task 24 | 25 | -c, --cpu-list 26 | specify a numerical list of processors instead of a bitmask. The list may contain multiple items, separated by comma, and ranges. For example, 0,5,7,9-11. 27 | -------------------------------------------------------------------------------- /ProdEnvDeploy/persistence.md: -------------------------------------------------------------------------------- 1 | #5.4 持久化设置 2 | RDB和AOF两者毫无关系，完全独立运行，如果使用了AOF，重启时只会从AOF文件载入数据，不会再管RDB文件。在配置上有三种选择：不持久化，RDB，RDB+AOF。官方不推荐只开启AOF（因为恢复太慢另外如果aof引擎有bug），除非明显的读多写少的应用。 3 | 开启AOF时应当关闭AOF自动rewrite，并在crontab中启动在业务低峰时段进行的bgrewrite。 4 | 如果在一台机器上部署多个redis实例，则关闭RDB和AOF的自动保存（save "", auto-aof-rewrite-percentage 0），通过crontab定时调用保存： 5 | 6 | m h * * * redis-cli -p BGSAVE 7 | m h */4 * * redis-cli -p BGREWRITEAOF 8 | 9 | 持久化的部署规划上，如果为主从复制关系，建议主关闭持久化。 10 | 11 | -------------------------------------------------------------------------------- /ProdEnvDeploy/rps.md: -------------------------------------------------------------------------------- 1 | #5.2 网卡RPS设置 2 | RPS就是让网卡使用多核CPU的。传统方法就是网卡多队列（RSS，需要硬件和驱动支持），RPS则是在系统层实现了分发和均衡。如果对redis网络处理能力要求高或者在生产上发现cpu0的，可以在OS层面打开这个内核功能。 3 | 4 | 5 | 设置脚本： 6 | 7 | #!/bin/bash 8 | # Enable RPS (Receive Packet Steering) 9 | 10 | rfc=32768 11 | cc=$(grep -c processor /proc/cpuinfo) 12 | rsfe=$(echo $cc*$rfc | bc) 13 | sysctl -w net.core.rps_sock_flow_entries=$rsfe 14 | for fileRps in $(ls /sys/class/net/eth*/queues/rx-*/rps_cpus) 15 | do 16 | echo fff > $fileRps 17 | done 18 | 19 | for fileRfc in $(ls /sys/class/net/eth*/queues/rx-*/rps_flow_cnt) 20 | do 21 | echo $rfc > $fileRfc 22 | done 23 | 24 | tail /sys/class/net/eth*/queues/rx-*/{rps_cpus,rps_flow_cnt} 25 | -------------------------------------------------------------------------------- /ProdEnvDeploy/servers.md: -------------------------------------------------------------------------------- 1 | #5.3 服务器部署位置 2 | 尽可能把client和server部署在同一台机器上，比如都部署在app server，或者一个网段中，减少网络延迟对于redis的影响。 3 | 4 | 5 | 如果是同一台机器，又想榨干redis性能可以考虑采用UNIX domain sockets配置方式，配置方式如下 6 | # 0 = do not listen on a port 7 | port 0 8 | 9 | # listen on localhost only 10 | bind 127.0.0.1 11 | 12 | # create a unix domain socket to listen on 13 | unixsocket /tmp/redis.sock 14 | 15 | # set permissions for the socket 16 | unixsocketperm 755 17 | 18 | 这样的配置方式在没有大量pipeline下会有一定性能提升，具体请参见http://redis.io/topics/benchmarks： 19 | 20 | 另外，对于混合部署即redis和应用部署在同一台服务器上，那么可能会出现如下的情况： 21 | 22 | >出现瞬时 Redis 大量连接和处理超时，应用业务线程被阻塞，导致服务拒绝，过一段时间可能又自动恢复了。这种瞬时故障非常难抓现场，一天来上几发就会给人业务不稳定的感受，而一般基础机器指标的监控周期在分钟级。瞬时故障可能发生在监控的采集间隙，所以只好上脚本在秒级监控日志，发现瞬时出现大量 Redis 超时错误，就收集当时应用的 JVM 堆栈、内存和机器 CPU Load 等各项指标。终于发现瞬时故障时刻 Redis 机器 CPU Load 出现瞬间飙升几百的现象，应用和 Redis 混合部署时应用可能瞬间抢占了全部 CPU 导致 Redis 没有 CPU 资源可用。而应用处理业务的逻辑又可能需要访问 Redis，而 Redis 又没有 CPU 资源可用导致超时，这不就像一个死锁么。搞清楚了原因其实解决方法也简单，就是分离应用和 Redis 的部署，各自资源隔离 23 | 24 | >出处： 25 | http://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=402004912&idx=1&sn=7517696a86f54262e60e1b5636d6cbe0&3rd=MzA3MDU4NTYzMw==&scene=6#rd 26 | 27 | 因此在混合部署下要对极限性能进行监控，提前将可能出现性能问题的应用迁移出来。 28 | 29 | -------------------------------------------------------------------------------- /Security/README.md: -------------------------------------------------------------------------------- 1 | #9. Redis安全问题 2 | 3 | Redis是一个弱安全的组件，只有一个简单的明文密码，因此在保护上需要对其他多方面的措施，另外，很多所谓安全问题不是redis本身造成的，而是误用的结果。 4 | -------------------------------------------------------------------------------- /Security/shell.md: -------------------------------------------------------------------------------- 1 | #9.1 Shell提权问题 2 | 问题报告：http://drops.wooyun.org/papers/3062 3 | 4 | 5 | 问题分析：Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。The Redis security model is: “it’s totally insecure to let untrusted clients access the system, please protect it from the outside world yourself”. 因此最近爆出的问题也非redis本身产品问题，属于不当配置。 6 | 7 | 问题规避： 8 | 9 | 1. 使用redis单独用户和组进行安全部署，并且在OS层面禁止此用户ssh登陆，这就从根本上防止了root用户启停redis带来的风险。 10 | 2. 修改默认端口，降低网络简单扫描危害。 11 | 3. 修改绑定地址，如果是本地访问要求绑定本地回环。 12 | 4. 要求设置密码，并对配置文件访问权限进行控制，因为密码在其中是明文。 13 | 5. HA环境下主从均要求设置密码。 另外，我们建议在网络防火墙层面进行保护，杜绝任何部署在外网直接可以访问的redis的出现。 14 | -------------------------------------------------------------------------------- /Testing/README.md: -------------------------------------------------------------------------------- 1 | # 9. 测试方法 -------------------------------------------------------------------------------- /Testing/aof-reload.md: -------------------------------------------------------------------------------- 1 | #7.6 模拟AOF加载情形 2 | debug loadaof 3 | 4 | 清空当前数据库，重新从aof文件里加载数据库 5 | emptyDb(); 6 | loadAppendOnlyFile(); 7 | -------------------------------------------------------------------------------- /Testing/down.md: -------------------------------------------------------------------------------- 1 | #7.2 模拟宕机 2 | redis-cli debug segfault 3 | -------------------------------------------------------------------------------- /Testing/hang.md: -------------------------------------------------------------------------------- 1 | #7.3 模拟hang 2 | redis-cli -p 6379 DEBUG sleep 30 3 | -------------------------------------------------------------------------------- /Testing/oom.md: -------------------------------------------------------------------------------- 1 | #7.1 模拟oom 2 | redis-cli debug oom 3 | redis直接退出。 4 | -------------------------------------------------------------------------------- /Testing/populate.md: -------------------------------------------------------------------------------- 1 | #7.4 快速产生测试数据 2 | debug populate 3 | 4 | 测试利器，快速产生大量的key 5 | 6 | 127.0.0.1:6379> debug populate 10000 7 | OK 8 | 127.0.0.1:6379> dbsize 9 | (integer) 10000 10 | -------------------------------------------------------------------------------- /Testing/rdb-reload.md: -------------------------------------------------------------------------------- 1 | #7.5 模拟RDB load情形 2 | debug reload 3 | 4 | save当前的rdb文件，并清空当前数据库，重新加载rdb，加载与启动时加载类似，加载过程中只能服务部分只读请求（比如info、ping等）： 5 | rdbSave(); 6 | emptyDb(); 7 | rdbLoad(); 8 | -------------------------------------------------------------------------------- /config.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Redis开发运维实践指南", 3 | "introduction": "中国民生银行总行科技部工程师-黄鹏程个人经验总结，最新 Redis 应用场景与最佳实践指南。", 4 | "path":{ 5 | "toc":"SUMMARY.md" 6 | } 7 | 8 | } -------------------------------------------------------------------------------- /cover/background.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/cover/background.jpg -------------------------------------------------------------------------------- /cover/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/cover/logo.png -------------------------------------------------------------------------------- /images/alipay-qrcode.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/alipay-qrcode.jpg -------------------------------------------------------------------------------- /images/lookingfor-100.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/lookingfor-100.jpg -------------------------------------------------------------------------------- /images/lookingfor.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/lookingfor.jpg -------------------------------------------------------------------------------- /images/redis-stat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/redis-stat.png -------------------------------------------------------------------------------- /images/weixin-group.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/weixin-group.png -------------------------------------------------------------------------------- /images/weixin-qrcode.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/weixin-qrcode.jpg -------------------------------------------------------------------------------- /images/xingqiu.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/images/xingqiu.jpg -------------------------------------------------------------------------------- /push.bat: -------------------------------------------------------------------------------- 1 | git add -A 2 | git commit -m %1% 3 | git push 4 | -------------------------------------------------------------------------------- /redisgroup: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnuhpc/All-About-Redis/17299af5db4548cde92ad50ac707a31beabc9378/redisgroup --------------------------------------------------------------------------------