首页 文章 精选 留言 我的

精选列表

搜索[水印魔术手]，共7332篇文章
优秀的个人博客,低调大师

《吊打面试官》系列-Redis哨兵、持久化、主从、手撕LRU?

你知道的越多，你不知道的越多 点赞再看，养成习惯 GitHub上已经开源https://github.com/Java...，有一线大厂面试点脑图，欢迎Star和完善 前言 Redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次offer的面霸（请允许我使用一下夸张的修辞手法），打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚，在一个寂寞难耐的夜晚，我痛定思痛，决定开始写《吊打面试官》系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 絮叨 写这期其实比较纠结，我之前的写的比较通俗易懂，一是我都知道这些点，二是之前我在所在的电商公司对雪崩，击穿啥的还算有场景去接触。但是线上的Redis集群我实际操作经验很少，总不能在公司线上环境实践那些操作吧，所以最后看了下官网，还有一些资料（文章后面我都会贴出来），强行怼了这么篇出来。 最近双十一小忙，周末双十一值班目测没时间写，那我是暖男呀，我不能鸽啊，就有了这一篇，下一篇迟到你们不要喷我哈，而且下一篇还是Redis的终章还是得构思下，不熟悉的知识点我怕漏洞多，特意让以前的大牛同事看了下，所以有啥不对的地方大家及时留言Diss我，写这篇是真的难，诺下面就是我本人某天凌晨两点的拍的视频，多动症的仔。 之前说过系列第二篇到300赞我就发第三篇 咋样没骗你们吧，就很枯竭，不BB了，开搞。 不点个赞对不起我，这次不要白嫖我！ 正文 上几期《吊打面试官》还没看的小伙伴可以回顾一下（明明就写了两期说的好像很多一样）！ 《吊打面试官》系列-Redis基础 《吊打面试官》系列-缓存雪崩、击穿、穿透 大家都知道一个技术的引入方便了开发，解决了各种问题，但是也会带来对应的问题，技术是把双刃剑嘛，集群的引入也会带来很多问题，如：集群的高可用怎么保证，数据怎么同步等等，我们话不多说，有请下一位受害者为我们展示。 面试开始 三个大腹便便，穿着格子衬衣的中年男子，拿着三个满是划痕的mac向你走来，看着快秃顶的头发，心想着肯定是尼玛顶级架构师吧！而且还是三个，但是还好我看过敖丙写的《吊打面试官》系列，腹有诗书气自华，根本虚都不虚好伐。 小伙子你好，之前问过了你基础知识以及一些缓存的常见几个大问题了，那你能跟我聊聊为啥Redis那么快么？ 哦，帅气迷人的面试官您好，我们可以先看一下关系型数据库跟Redis本质上的区别。 Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)； 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的； 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗； 使用多路I/O复用模型，非阻塞IO； 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求； 我可以问一下啥是上下文切换么？ 我可以打个比方么：我记得有过一个小伙伴微信问过我上下文切换是啥，为啥可能会线程不安全，我是这么说的，就好比你看一本英文书，你看到第十页发现有个单词不会读，你加了个书签，然后去查字典，过了一会你又回来继续从书签那里读，ok到目前为止没啥问题。 如果是你一个人读肯定没啥问题，但是你去查的时候，别的小伙伴好奇你在看啥他就翻了一下你的书，然后溜了，哦豁，你再看的时候就发现书不是你看的那一页了。不知道到这里为止我有没有解释清楚，以及为啥会线程不安全，就是因为你一个人怎么看都没事，但是人多了换来换去的操作一本书数据就乱了。可能我的解释很粗糙，但是道理应该是一样的。 那他是单线程的，我们现在服务器都是多核的，那不是很浪费？ 是的他是单线程的，但是，我们可以通过在单机开多个Redis实例嘛。 既然提到了单机会有瓶颈，那你们是怎么解决这个瓶颈的？ 我们用到了集群的部署方式也就是Redis cluster，并且是主从同步读写分离，类似Mysql的主从同步，Redis cluster 支撑 N 个 Redis master node，每个master node都可以挂载多个 slave node。 这样整个 Redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。 哦？那问题就来了，他们之间是怎么进行数据交互的？以及Redis是怎么进行持久化的？Redis数据都在内存中，一断电或者重启不就木有了嘛？ 是的，持久化的话是Redis高可用中比较重要的一个环节，因为Redis数据在内存的特性，持久化必须得有，我了解到的持久化是有两种方式的。 RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。 AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。 两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备，比如我杭州的某电商公司有这两个数据，我备份一份到我杭州的节点，再备份一个到上海的，就算发生无法避免的自然灾害，也不会两个地方都一起挂吧，这灾备也就是异地容灾，地球毁灭他没办法。 tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。 那这两种机制各自优缺点是啥？ 我先说RDB吧 优点： 他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，有没有觉得很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。 RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。 缺点： RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判。 还有就是RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，哦豁，出大问题。 我们再来说说AOF 优点： 上面提到了，RDB五分钟一次生成快照，但是AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。 AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。 AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。 tip：我说的命令你们别真去线上系统操作啊，想试去自己买的服务器上装个Redis试，别到时候来说，敖丙真是个渣男，害我把服务器搞崩了，Redis官网上的命令都去看看，不要乱试！！！ 缺点： 一样的数据，AOF文件比RDB还要大。 AOF开启后，Redis支持写的QPS会比RDB支持写的要低，他不是每秒都要去异步刷新一次日志嘛fsync，当然即使这样性能还是很高，我记得ElasticSearch也是这样的，异步刷新缓存区的数据去持久化，为啥这么做呢，不直接来一条怼一条呢，那我会告诉你这样性能可能低到没办法用的，大家可以思考下为啥哟。 那两者怎么选择？ 小孩子才做选择，我全都要，你单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快，真出什么时候第一时间用RDB恢复，然后AOF做数据补全，真香！冷备热备一起上，才是互联网时代一个高健壮性系统的王道。 看不出来年纪轻轻有点东西的呀，对了我听你提到了高可用，Redis还有其他保证集群高可用的方式么？ ！！！晕 自己给自己埋个坑（其实是明早就准备好了，故意抛出这个词等他问，就怕他不问）。 假装思考一会（不要太久，免得以为你真的不会），哦我想起来了，还有哨兵集群sentinel。 哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。 为啥必须要三个实例呢？我们先看看两个哨兵会咋样。 master宕机了 s1和s2两个哨兵只要有一个认为你宕机了就切换了，并且会选举出一个哨兵去执行故障，但是这个时候也需要大多数哨兵都是运行的。 那这样有啥问题呢？M1宕机了，S1没挂那其实是OK的，但是整个机器都挂了呢？哨兵就只剩下S2个裸屌了，没有哨兵去允许故障转移了，虽然另外一个机器上还有R1，但是故障转移就是不执行。 经典的哨兵集群是这样的： M1所在的机器挂了，哨兵还有两个，两个人一看他不是挂了嘛，那我们就选举一个出来执行故障转移不就好了。 暖男我，小的总结下哨兵组件的主要功能： 集群监控：负责监控 Redis master 和 slave 进程是否正常工作。 消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。 我记得你还提到了主从同步，能说一下主从之间的数据怎么同步的么？ 面试官您的记性可真是一级棒呢，我都要忘了你还记得，我特么谢谢你，提到这个，就跟我前面提到的数据持久化的RDB和AOF有着比密切的关系了。 我先说下为啥要用主从这样的架构模式，前面提到了单机QPS是有上限的，而且Redis的特性就是必须支撑读高并发的，那你一台机器又读又写，这谁顶得住啊，不当人啊！但是你让这个master机器去写，数据同步给别的slave机器，他们都拿去读，分发掉大量的请求那是不是好很多，而且扩容的时候还可以轻松实现水平扩容。 回归正题，他们数据怎么同步的呢？ 你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。 数据传输的时候断网了或者服务器挂了怎么办啊？ 传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。 大家需要记得的就是，RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办？是吧？ 那说了这么多你能说一下他的内存淘汰机制么，来手写一下LRU代码？ 手写LRU？你是不是想直接跳起来说一句：Are U F**k Kidding me？ 这个问题是我在蚂蚁金服三面的时候亲身被问过的问题，不知道大家有没有被怼到过这个问题。 Redis的过期策略，是有定期删除+惰性删除两种。 定期好理解，默认100s就随机抽一些设置了过期时间的key，去检查是否过期，过期了就删了。 为啥不扫描全部设置了过期时间的key呢？ 假如Redis里面所有的key都有过期时间，都扫描一遍？那太恐怖了，而且我们线上基本上也都是会设置一定的过期时间的。全扫描跟你去查数据库不带where条件不走索引全表扫描一样，100s一次，Redis累都累死了。 如果一直没随机到很多key，里面不就存在大量的无效key了？ 好问题，惰性删除，见名知意，惰性嘛，我不主动删，我懒，我等你来查询了我看看你过期没，过期就删了还不给你返回，没过期该怎么样就怎么样。 最后就是如果的如果，定期没删，我也没查询，那可咋整？ 内存淘汰机制！ 官网上给到的内存淘汰机制是以下几个： noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外） allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。 volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。 allkeys-random: 回收随机的键使得新添加的数据有空间存放。 volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。 volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。 如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。 至于LRU我也简单提一下，手写实在是太长了，大家可以去Redis官网看看，我把近视LUR效果给大家看看 tip：Redis为什么不使用真实的LRU实现是因为这需要太多的内存。不过近似的LRU算法对于应用而言应该是等价的。使用真实的LRU算法与近似的算法可以通过下面的图像对比。 LRU comparison 你可以看到三种点在图片中, 形成了三种带. 浅灰色带是已经被回收的对象。 灰色带是没有被回收的对象。 绿色带是被添加的对象。 在LRU实现的理论中，我们希望的是，在旧键中的第一半将会过期。Redis的LRU算法则是概率的过期旧的键。 你可以看到，在都是五个采样的时候Redis 3.0比Redis 2.8要好，Redis2.8中在最后一次访问之间的大多数的对象依然保留着。使用10个采样大小的Redis 3.0的近似值已经非常接近理论的性能。 注意LRU只是个预测键将如何被访问的模型。另外，如果你的数据访问模式非常接近幂定律，大部分的访问将集中在一个键的集合中，LRU的近似算法将处理得很好。 其实在大家熟悉的LinkedHashMap中也实现了Lru算法的，实现如下： 当容量超过100时，开始执行LRU策略：将最近最少未使用的 TimeoutInfoHolder 对象 evict 掉。 真实面试中会让你写LUR算法，你可别搞原始的那个，那真TM多，写不完的，你要么怼上面这个，要么怼下面这个，找一个数据结构实现下Java版本的LRU还是比较容易的，知道啥原理就好了。 面试结束 小伙子，你确实有点东西，HRBP会联系你的，请务必保持你的手机畅通好么？ 好的谢谢面试官，面试官真好，我还想再面几次，噗此。 能回答得这么全面这么细节还是忍不住点赞 （暗示点赞，每次都看了不点赞，你们想白嫖我么？你们好坏喲，不过我好喜欢） 总结 好了，我们玩归玩，闹归闹，别拿面试开玩笑，我这么写是为了节目效果，大家面试请认真对待。 这一期是这期没前面好理解了对吧，我就在自己的服务器上启动了，然后再去官网看看命令一顿瞎操作的，查阅了部分资料，这里给大家推荐几本经典的Redis入门的书籍和我参考的资料。 Redis中文官网 《Redis入门指南(第2版)》 《Redis实战》 《Redis设计与实现》 《大型网站技术架构——李智慧》 《Redis 设计与实现——黄健宏》 《Redis 深度历险——钱文品》 《亿级流量网站架构核心技术——张开涛》 《中华石杉——石杉》 不出意外的话这是Redis的倒数第二期，最后一期不知道写啥还没想好，我得好好想想，加上最近不是双十一嘛得加加班，你看看开头的我，多可怜，那还不点个赞？买个服务器？不确定下一期多久出，想早点看到更新的小伙伴可以去公众号催更，公众号提前一到两天更新。 END 好了各位，以上就是这篇文章的全部内容了，能看到这里的人呀，都是人才。 我后面会每周都更新几篇《吊打面试官》系列和互联网常用技术栈相关的文章，欢迎关注我的个人公众号：JavaFamily 第一时间阅读。 非常感谢人才们能看到这里，如果这个文章写得还不错，觉得「敖丙」我有点东西的话 求点赞👍 求关注❤️ 求分享👥 求留言💬 对暖男我来说真的 非常有用！！！ 创作不易，各位的支持和认可，就是我创作的最大动力，我们下篇文章见！ 敖丙 | 文 【原创】【转载请联系本人】 如果本篇博客有任何错误，请批评指教，不胜感激 ！ 《吊打面试官》系列每周持续更新，可以关注我的公众号JavaFamily第一时间阅读和催更（公众号比博客早一到两篇哟），【GitHub】上已经收录https://github.com/Java...，有一线大厂面试点思维导图，欢迎Star和完善，里面也有我个人微信有什么问题也可以直接滴滴我，我们一起有点东西。
2019-11-07
优秀的个人博客,低调大师

《吊打面试官》系列-Redis哨兵、持久化、主从、手撕LRU

你知道的越多，你不知道的越多 点赞再看，养成习惯 前言 Redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次offer的面霸（请允许我使用一下夸张的修辞手法），打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚，在一个寂寞难耐的夜晚，我痛定思痛，决定开始写《吊打面试官》系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 絮叨 写这期其实比较纠结，我之前的写的比较通俗易懂，一是我都知道这些点，二是之前我在所在的电商公司对雪崩，击穿啥的还算有场景去接触。但是线上的Redis集群我实际操作经验很少，总不能在公司线上环境实践那些操作吧，所以最后看了下官网，还有一些资料（文章后面我都会贴出来），强行怼了这么篇出来。 最近双十一小忙，周末双十一值班目测没时间写，那我是暖男呀，我不能鸽啊，就有了这一篇，下一篇迟到你们不要喷我哈，而且下一篇还是Redis的终章还是得构思下，不熟悉的知识点我怕漏洞多，特意让以前的大牛同事看了下，所以有啥不对的地方大家及时留言Diss我，写这篇是真的难，诺下面就是我本人某天凌晨两点的拍的视频，多动症的仔。 之前说过系列第二篇到300赞我就发第三篇 咋样没骗你们吧，就很枯竭，不BB了，开搞。 不点个赞对不起我，这次不要白嫖我！ 正文 上几期《吊打面试官》还没看的小伙伴可以回顾一下（明明就写了两期说的好像很多一样）！ 《吊打面试官》系列-Redis基础 《吊打面试官》系列-缓存雪崩、击穿、穿透 大家都知道一个技术的引入方便了开发，解决了各种问题，但是也会带来对应的问题，技术是把双刃剑嘛，集群的引入也会带来很多问题，如：集群的高可用怎么保证，数据怎么同步等等，我们话不多说，有请下一位受害者为我们展示。 面试开始 三个大腹便便，穿着格子衬衣的中年男子，拿着三个满是划痕的mac向你走来，看着快秃顶的头发，心想着肯定是尼玛顶级架构师吧！而且还是三个，但是还好我看过敖丙写的《吊打面试官》系列，腹有诗书气自华，根本虚都不虚好伐。 小伙子你好，之前问过了你基础知识以及一些缓存的常见几个大问题了，那你能跟我聊聊为啥Redis那么快么？ 哦，帅气迷人的面试官您好，我们可以先看一下关系型数据库跟Redis本质上的区别。 Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)； 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的； 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗； 使用多路I/O复用模型，非阻塞IO； 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求； 我可以问一下啥是上下文切换么？ 我可以打个比方么：我记得有过一个小伙伴微信问过我上下文切换是啥，为啥可能会线程不安全，我是这么说的，就好比你看一本英文书，你看到第十页发现有个单词不会读，你加了个书签，然后去查字典，过了一会你又回来继续从书签那里读，ok到目前为止没啥问题。 如果是你一个人读肯定没啥问题，但是你去查的时候，别的小伙伴好奇你在看啥他就翻了一下你的书，然后溜了，哦豁，你再看的时候就发现书不是你看的那一页了。不知道到这里为止我有没有解释清楚，以及为啥会线程不安全，就是因为你一个人怎么看都没事，但是人多了换来换去的操作一本书数据就乱了。可能我的解释很粗糙，但是道理应该是一样的。 那他是单线程的，我们现在服务器都是多核的，那不是很浪费？ 是的他是单线程的，但是，我们可以通过在单机开多个Redis实例嘛。 既然提到了单机会有瓶颈，那你们是怎么解决这个瓶颈的？ 我们用到了集群的部署方式也就是Redis cluster，并且是主从同步读写分离，类似Mysql的主从同步，Redis cluster 支撑 N 个 Redis master node，每个master node都可以挂载多个 slave node。 这样整个 Redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。 哦？那问题就来了，他们之间是怎么进行数据交互的？以及Redis是怎么进行持久化的？Redis数据都在内存中，一断电或者重启不就木有了嘛？ 是的，持久化的话是Redis高可用中比较重要的一个环节，因为Redis数据在内存的特性，持久化必须得有，我了解到的持久化是有两种方式的。 RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。 AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。 两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备，比如我杭州的某电商公司有这两个数据，我备份一份到我杭州的节点，再备份一个到上海的，就算发生无法避免的自然灾害，也不会两个地方都一起挂吧，这灾备也就是异地容灾，地球毁灭他没办法。 tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。 那这两种机制各自优缺点是啥？ 我先说RDB吧 优点： 他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，有没有觉得很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。 RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。 缺点： RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判。 还有就是RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，哦豁，出大问题。 我们再来说说AOF 优点： 上面提到了，RDB五分钟一次生成快照，但是AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。 AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。 AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。 tip：我说的命令你们别真去线上系统操作啊，想试去自己买的服务器上装个Redis试，别到时候来说，敖丙真是个渣男，害我把服务器搞崩了，Redis官网上的命令都去看看，不要乱试！！！ 缺点： 一样的数据，AOF文件比RDB还要大。 AOF开启后，Redis支持写的QPS会比RDB支持写的要低，他不是每秒都要去异步刷新一次日志嘛fsync，当然即使这样性能还是很高，我记得ElasticSearch也是这样的，异步刷新缓存区的数据去持久化，为啥这么做呢，不直接来一条怼一条呢，那我会告诉你这样性能可能低到没办法用的，大家可以思考下为啥哟。 那两者怎么选择？ 小孩子才做选择，我全都要，你单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快，真出什么时候第一时间用RDB恢复，然后AOF做数据补全，真香！冷备热备一起上，才是互联网时代一个高健壮性系统的王道。 看不出来年纪轻轻有点东西的呀，对了我听你提到了高可用，Redis还有其他保证集群高可用的方式么？ ！！！晕 自己给自己埋个坑（其实是明早就准备好了，故意抛出这个词等他问，就怕他不问）。 假装思考一会（不要太久，免得以为你真的不会），哦我想起来了，还有哨兵集群sentinel。 哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。 为啥必须要三个实例呢？我们先看看两个哨兵会咋样。 master宕机了 s1和s2两个哨兵只要有一个认为你宕机了就切换了，并且会选举出一个哨兵去执行故障，但是这个时候也需要大多数哨兵都是运行的。 那这样有啥问题呢？M1宕机了，S1没挂那其实是OK的，但是整个机器都挂了呢？哨兵就只剩下S2个裸屌了，没有哨兵去允许故障转移了，虽然另外一个机器上还有R1，但是故障转移就是不执行。 经典的哨兵集群是这样的： M1所在的机器挂了，哨兵还有两个，两个人一看他不是挂了嘛，那我们就选举一个出来执行故障转移不就好了。 暖男我，小的总结下哨兵组件的主要功能： 集群监控：负责监控 Redis master 和 slave 进程是否正常工作。 消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。 我记得你还提到了主从同步，能说一下主从之间的数据怎么同步的么？ 面试官您的记性可真是一级棒呢，我都要忘了你还记得，我特么谢谢你，提到这个，就跟我前面提到的数据持久化的RDB和AOF有着比密切的关系了。 我先说下为啥要用主从这样的架构模式，前面提到了单机QPS是有上限的，而且Redis的特性就是必须支撑读高并发的，那你一台机器又读又写，这谁顶得住啊，不当人啊！但是你让这个master机器去写，数据同步给别的slave机器，他们都拿去读，分发掉大量的请求那是不是好很多，而且扩容的时候还可以轻松实现水平扩容。 回归正题，他们数据怎么同步的呢？ 你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。 数据传输的时候断网了或者服务器挂了怎么办啊？ 传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。 大家需要记得的就是，RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办？是吧？ 那说了这么多你能说一下他的内存淘汰机制么，来手写一下LRU代码？ 手写LRU？你是不是想直接跳起来说一句：Are U F**k Kidding me？ 这个问题是我在蚂蚁金服三面的时候亲身被问过的问题，不知道大家有没有被怼到过这个问题。 Redis的过期策略，是有定期删除+惰性删除两种。 定期好理解，默认100s就随机抽一些设置了过期时间的key，去检查是否过期，过期了就删了。 为啥不扫描全部设置了过期时间的key呢？ 假如Redis里面所有的key都有过期时间，都扫描一遍？那太恐怖了，而且我们线上基本上也都是会设置一定的过期时间的。全扫描跟你去查数据库不带where条件不走索引全表扫描一样，100s一次，Redis累都累死了。 如果一直没随机到很多key，里面不就存在大量的无效key了？ 好问题，惰性删除，见名知意，惰性嘛，我不主动删，我懒，我等你来查询了我看看你过期没，过期就删了还不给你返回，没过期该怎么样就怎么样。 最后就是如果的如果，定期没删，我也没查询，那可咋整？ 内存淘汰机制！ 官网上给到的内存淘汰机制是以下几个： noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外） allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。 volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。 allkeys-random: 回收随机的键使得新添加的数据有空间存放。 volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。 volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。 如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。 至于LRU我也简单提一下，手写实在是太长了，大家可以去Redis官网看看，我把近视LUR效果给大家看看 tip：Redis为什么不使用真实的LRU实现是因为这需要太多的内存。不过近似的LRU算法对于应用而言应该是等价的。使用真实的LRU算法与近似的算法可以通过下面的图像对比。 LRU comparison 你可以看到三种点在图片中, 形成了三种带. 浅灰色带是已经被回收的对象。 灰色带是没有被回收的对象。 绿色带是被添加的对象。 在LRU实现的理论中，我们希望的是，在旧键中的第一半将会过期。Redis的LRU算法则是概率的过期旧的键。 你可以看到，在都是五个采样的时候Redis 3.0比Redis 2.8要好，Redis2.8中在最后一次访问之间的大多数的对象依然保留着。使用10个采样大小的Redis 3.0的近似值已经非常接近理论的性能。 注意LRU只是个预测键将如何被访问的模型。另外，如果你的数据访问模式非常接近幂定律，大部分的访问将集中在一个键的集合中，LRU的近似算法将处理得很好。 其实在大家熟悉的LinkedHashMap中也实现了Lru算法的，实现如下： 当容量超过100时，开始执行LRU策略：将最近最少未使用的 TimeoutInfoHolder 对象 evict 掉。 真实面试中会让你写LUR算法，你可别搞原始的那个，那真TM多，写不完的，你要么怼上面这个，要么怼下面这个，找一个数据结构实现下Java版本的LRU还是比较容易的，知道啥原理就好了。 面试结束 小伙子，你确实有点东西，HRBP会联系你的，请务必保持你的手机畅通好么？ 好的谢谢面试官，面试官真好，我还想再面几次，噗此。 能回答得这么全面这么细节还是忍不住点赞 （暗示点赞，每次都看了不点赞，你们想白嫖我么？你们好坏喲，不过我好喜欢） 总结 好了，我们玩归玩，闹归闹，别拿面试开玩笑，我这么写是为了节目效果，大家面试请认真对待。 这一期是这期没前面好理解了对吧，我就在自己的服务器上启动了，然后再去官网看看命令一顿瞎操作的，查阅了部分资料，这里给大家推荐几本经典的Redis入门的书籍和我参考的资料。 Redis中文官网 《Redis入门指南(第2版)》 《Redis实战》 《Redis设计与实现》 《大型网站技术架构——李智慧》 《Redis 设计与实现——黄健宏》 《Redis 深度历险——钱文品》 《亿级流量网站架构核心技术——张开涛》 《中华石杉——石杉》 不出意外的话这是Redis的倒数第二期，最后一期不知道写啥还没想好，我得好好想想，加上最近不是双十一嘛得加加班，你看看开头的我，多可怜，那还不点个赞？买个服务器？不确定下一期多久出，想早点看到更新的小伙伴可以去公众号催更，公众号提前一到两天更新。 END 好了各位，以上就是这篇文章的全部内容了，能看到这里的人呀，都是人才，我后面会每周都更新几篇《吊打面试官》系列和Java技术栈相关的文章。如果你有什么想知道的，也可以留言给我，我一有时间就会写出来，我们共同进步。 非常感谢靓仔/靓女您能看到这里，如果这个文章写得还不错，觉得敖丙有点东西 求点赞 求关注 求分享 求留言 （对我非常有用）各位的支持和认可，就是我创作的最大动力，我们下篇文章见！ 敖丙 | 文 【原创】 每周都会持续更新《吊打面试官》系列可以关注我的公众号第一时间阅读和催更，公众号比博客提前一到两天更新，也可以在公众号回复【人才】加入人才交流群，里面都是人才长得好看说话还好听，进去就像回家了一样，就业和工作上有什么问题也可以直接滴滴我，我也是个新人，不过不影响我们一起进步。
2019-11-07
优秀的个人博客,低调大师

手淘千牛IM即时通信 - 星巴克消息开放实践

对垂直业务领域进行了解，抽象成领域模型，沉淀出通用能力和标准化体系，为后续业务赋能。 这是笔者理解的技术驱动业务。生于业务，又高于业务 笔者很荣幸可以参与到淘宝小程序的开放体系中，消息能力的开放也是里面很重要的一环，在双十一前可以借助星巴克小程序把消息方案落地，这次做个总结。 这次星巴克消息开放融合带来的挑战是：底层需要对接不同的服务体系，他们之间的协议不一致，上层业务业务又需要统一，而且整个开发迭代节奏很快。 本文主要会从垂直领域行业（包括淘系）的现状，到IM的基本概念及流程，到方案选型分层，到核心模块的设计，到后续的规划思考几个方面来讲述，做个自己的思考，让大家有个全方面的理解。 文章提纲 行业情况（淘外和淘内），包括IM即时通信能力和IM产品 IM的基本概念及流程 方案的选型和设计 核心模块（消息处理中心）能力抽象，参考Koajs的中间件
2018-11-28
优秀的个人博客,低调大师

Centos0S7手动安装OpenStack Pike版--(glance)

#Configure Glance mysql -uroot -ppasswd123 -e "CREATE DATABASE glance" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON glance.TO 'glance'@'localhost' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON glance.TO 'glance'@'%' IDENTIFIED BY 'passwd123'" openstack user create --domain default --password passwd123 glance openstack role add --project service --user glance admin openstack service create --name glance --description "OpenStack Image" image openstack endpoint create --region RegionOne image publichttp://controller:9292 openstack endpoint create --region RegionOne image internalhttp://controller:9292 openstack endpoint create --region RegionOne image adminhttp://controller:9292 openstack-config --set /etc/glance/glance-api.conf database connection mysql+pymysql://glance:passwd123@controller/glance openstack-config --set /etc/glance/glance-api.conf keystone_authtoken auth_urihttp://controller:5000 openstack-config --set /etc/glance/glance-api.conf keystone_authtoken auth_urlhttp://controller:35357 openstack-config --set /etc/glance/glance-api.conf keystone_authtoken memcached_servers controller:11211 openstack-config --set /etc/glance/glance-api.conf keystone_authtoken auth_type password openstack-config --set /etc/glance/glance-api.conf keystone_authtoken project_domain_name Default openstack-config --set /etc/glance/glance-api.conf keystone_authtoken user_domain_name Default openstack-config --set /etc/glance/glance-api.conf keystone_authtoken project_name service openstack-config --set /etc/glance/glance-api.conf keystone_authtoken username glance openstack-config --set /etc/glance/glance-api.conf keystone_authtoken password passwd123 openstack-config --set /etc/glance/glance-api.conf paste_deploy flavor keystone openstack-config --set /etc/glance/glance-api.conf glance_store stores file,http openstack-config --set /etc/glance/glance-api.conf glance_store default_store file openstack-config --set /etc/glance/glance-api.conf glance_store filesystem_store_datadir /var/lib/glance/images/ /etc/glance/glance-registry.conf openstack-config --set /etc/glance/glance-registry.conf database connection mysql+pymysql://glance:passwd123@controller/glance openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken auth_urihttp://controller:5000 openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken auth_urlhttp://controller:35357 openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken memcached_servers controller:11211 openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken auth_type password openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken project_domain_name Default openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken user_domain_name Default openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken project_name service openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken username glance openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken password passwd123 openstack-config --set /etc/glance/glance-registry.conf paste_deploy flavor keystone su -s /bin/sh -c "glance-manage db_sync" glance systemctl enable openstack-glance-api.service openstack-glance-registry.service systemctl start openstack-glance-api.service openstack-glance-registry.service systemctl status openstack-glance-api.service openstack-glance-registry.service source admin-openrc openstack image create "centos7" --file CentOS-7-x86_64-GenericCloud.qcow2 --disk-format qcow2 --container-format bare --public openstack image list 本文转自 OpenStack2015 博客，原文链接： http://blog.51cto.com/andyliu/2069164 如需转载请自行联系原作者
2017-11-22
优秀的个人博客,低调大师

Centos0S7手动安装OpenStack Pike版--(keystone)

OpenStack安装指南_Mitakahttp://down.51cto.com/data/2331199 Openstack管理手册-Newton版-CentOS7.2http://down.51cto.com/data/2331201 #Configure Keystone mysql -uroot -ppasswd123 -e "CREATE DATABASE keystone" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON keystone.TO 'keystone'@'localhost' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON keystone.TO 'keystone'@'%' IDENTIFIED BY 'passwd123'" vim /etc/keystone/keystone.conf [database] connection = mysql+pymysql://keystone:passwd123@controller/keystone [token] provider = fernet su -s /bin/sh -c "keystone-manage db_sync" keystone keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone keystone-manage credential_setup --keystone-user keystone --keystone-group keystone keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-urlhttp://controller:35357/v3/\ --bootstrap-internal-urlhttp://controller:5000/v3/\ --bootstrap-public-urlhttp://controller:5000/v3/\ --bootstrap-region-id RegionOne Configure the Apache HTTP server vim /etc/httpd/conf/httpd.conf ServerName controller ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/ systemctl start httpd.service systemctl enable httpd.service systemctl status httpd.service export OS_USERNAME=admin export OS_PASSWORD=passwd123 export OS_PROJECT_NAME=admin export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_DOMAIN_NAME=Default export OS_AUTH_URL=http://controller:35357/v3 export OS_IDENTITY_API_VERSION=3 openstack project create --domain default --description "Service Project" service openstack project create --domain default --description "Demo Project" demo openstack user create --domain default --password passwd123 demo openstack role create user openstack role add --project demo --user demo user unset OS_AUTH_URL OS_PASSWORD openstack --os-auth-urlhttp://controller:35357/v3\ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue openstack --os-auth-urlhttp://controller:5000/v3\ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name demo --os-username demo token issue vim admin-openrc export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=passwd123 export OS_AUTH_URL=http://controller:35357/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 source admin-openrc openstack token issue 本文转自 OpenStack2015 博客，原文链接： http://blog.51cto.com/andyliu/2069163 如需转载请自行联系原作者
2017-11-16
优秀的个人博客,低调大师

Centos0S7手动安装OpenStack Pike版--(Evironment)

OpenStack安装指南_Mitakahttp://down.51cto.com/data/2331199 Openstack管理手册-Newton版-CentOS7.2http://down.51cto.com/data/2331201 [root@controller ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 192.168.137.145 controller 192.168.137.146 compute 192.168.137.149 storage #Install ALL Packages and Configure Evironment yum install centos-release-openstack-pike -y yum install python-openstackclient -y yum install openstack-selinux -y yum install mariadb mariadb-server python2-PyMySQL -y yum install rabbitmq-server -y yum install memcached python-memcached -y yum install etcd -y yum install openstack-keystone httpd mod_wsgi -y yum install openstack-glance -y yum install -y openstack-nova-api openstack-nova-conductor \ openstack-nova-console openstack-nova-novncproxy \ openstack-nova-scheduler openstack-nova-placement-api yum install -y openstack-neutron openstack-neutron-ml2 \ openstack-neutron-linuxbridge ebtables #Configure RabbitMQ systemctl enable rabbitmq-server.service systemctl start rabbitmq-server.service systemctl status rabbitmq-server.service rabbitmqctl add_user openstack passwd123 rabbitmqctl set_permissions openstack "." "." ".*" #Configure Memcached vim /etc/sysconfig/memcached OPTIONS="-l 127.0.0.1,::1,controller" systemctl enable memcached.service systemctl start memcached.service OpenStack服务可以使用户可靠，分布式键值存储的分布式密钥锁定，存储配置，跟踪服务活性等情况。 #Configure Etcd vim /etc/etcd/etcd.conf [root@controller ~]# vim /etc/etcd/etcd.conf #[Member] ETCD_DATA_DIR="/var/lib/etcd/default.etcd" ETCD_LISTEN_PEER_URLS="http://192.168.137.145:2380" ETCD_LISTEN_CLIENT_URLS="http://192.168.137.145:2379" ETCD_NAME="controller" #[Clustering] ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.137.145:2380" ETCD_ADVERTISE_CLIENT_URLS="http://192.168.137.145:2379" ETCD_INITIAL_CLUSTER="controller=http://192.168.137.145:2380" ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01" ETCD_INITIAL_CLUSTER_STATE="new" systemctl enable etcd systemctl start etcd systemctl status etcd 本文转自 OpenStack2015 博客，原文链接：http://blog.51cto.com/andyliu/2069162 如需转载请自行联系原作者
2017-11-15
优秀的个人博客,低调大师

Centos0S7手动安装OpenStack Pike版--(nova)

OpenStack安装指南_Mitakahttp://down.51cto.com/data/2331199 Openstack管理手册-Newton版-CentOS7.2http://down.51cto.com/data/2331201 #Configure Nova mysql -uroot -ppasswd123 -e "CREATE DATABASE nova_api" mysql -uroot -ppasswd123 -e "CREATE DATABASE nova" mysql -uroot -ppasswd123 -e "CREATE DATABASE nova_cell0" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova_api.TO 'nova'@'localhost' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova_api.TO 'nova'@'%' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova.TO 'nova'@'localhost' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova.TO 'nova'@'%' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova_cell0.TO 'nova'@'localhost' IDENTIFIED BY 'passwd123'" mysql -uroot -ppasswd123 -e "GRANT ALL PRIVILEGES ON nova_cell0.TO 'nova'@'%' IDENTIFIED BY 'passwd123'" source admin-openrc openstack user create --domain default --password passwd123 nova openstack role add --project service --user nova admin openstack service create --name nova --description "OpenStack Compute" compute openstack endpoint create --region RegionOne compute publichttp://controller:8774/v2.1 openstack endpoint create --region RegionOne compute internalhttp://controller:8774/v2.1 openstack endpoint create --region RegionOne compute adminhttp://controller:8774/v2.1 openstack user create --domain default --password paswd123 placement openstack role add --project service --user placement admin openstack service create --name placement --description "Placement API" placement openstack endpoint create --region RegionOne placement publichttp://controller:8778 openstack endpoint create --region RegionOne placement internalhttp://controller:8778 openstack endpoint create --region RegionOne placement adminhttp://controller:8778 Edit the /etc/nova/nova.conf openstack-config --set /etc/nova/nova.conf DEFAULT enabled_apis osapi_compute,metadata openstack-config --set /etc/nova/nova.conf api_database connection mysql+pymysql://nova:passwd123@controller/nova_api openstack-config --set /etc/nova/nova.conf database connection mysql+pymysql://nova:passwd123@controller/nova openstack-config --set /etc/nova/nova.conf DEFAULT transport_url rabbit://openstack:passwd123@controller openstack-config --set /etc/nova/nova.conf api auth_strategy keystone openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_urihttp://controller:5000 openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_urlhttp://controller:35357 openstack-config --set /etc/nova/nova.conf keystone_authtoken memcached_servers controller:11211 openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_type password openstack-config --set /etc/nova/nova.conf keystone_authtoken project_domain_name default openstack-config --set /etc/nova/nova.conf keystone_authtoken user_domain_name default openstack-config --set /etc/nova/nova.conf keystone_authtoken project_name service openstack-config --set /etc/nova/nova.conf keystone_authtoken username nova openstack-config --set /etc/nova/nova.conf keystone_authtoken password passwd123 openstack-config --set /etc/nova/nova.conf DEFAULT my_ip 192.168.137.145 openstack-config --set /etc/nova/nova.conf DEFAULT use_neutron True openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver nova.virt.firewall.NoopFirewallDriver openstack-config --set /etc/nova/nova.conf vnc enabled true openstack-config --set /etc/nova/nova.conf vnc vncserver_listen 192.168.137.145 openstack-config --set /etc/nova/nova.conf vnc vncserver_proxyclient_address 192.168.137.145 openstack-config --set /etc/nova/nova.conf glance api_servershttp://controller:9292 openstack-config --set /etc/nova/nova.conf oslo_concurrency lock_path /var/lib/nova/tmp openstack-config --set /etc/nova/nova.conf placement os_region_name RegionOne openstack-config --set /etc/nova/nova.conf placement project_domain_name Default openstack-config --set /etc/nova/nova.conf placement project_name service openstack-config --set /etc/nova/nova.conf placement auth_type password openstack-config --set /etc/nova/nova.conf placement user_domain_name Default openstack-config --set /etc/nova/nova.conf placement auth_urlhttp://controller:35357/v3 openstack-config --set /etc/nova/nova.conf placement username placement openstack-config --set /etc/nova/nova.conf placement password passwd123 vim /etc/httpd/conf.d/00-nova-placement-api.conf <Directory /usr/bin> <IfVersion >= 2.4> Require all granted </IfVersion> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> </Directory> systemctl restart httpd systemctl status httpd su -s /bin/sh -c "nova-manage api_db sync" nova su -s /bin/sh -c "nova-manage cell_v2 map_cell0" nova su -s /bin/sh -c "nova-manage cell_v2 create_cell --name=cell1 --verbose" nova su -s /bin/sh -c "nova-manage db sync" nova nova-manage cell_v2 list_cells systemctl enable openstack-nova-api.service openstack-nova-consoleauth.service openstack-nova-scheduler.service \ openstack-nova-conductor.service openstack-nova-novncproxy.service systemctl start openstack-nova-api.service openstack-nova-consoleauth.service openstack-nova-scheduler.service \ openstack-nova-conductor.service openstack-nova-novncproxy.service systemctl status openstack-nova-api.service openstack-nova-consoleauth.service openstack-nova-scheduler.service \ openstack-nova-conductor.service openstack-nova-novncproxy.service openstack service list 本文转自 OpenStack2015 博客，原文链接： http://blog.51cto.com/andyliu/2069165 如需转载请自行联系原作者
2017-11-14
优秀的个人博客,低调大师

物联网推动城市发展 诊治“城市病”很有一手

城市发展要走集约、智慧、绿色的新兴道路，这个思路必须通过“互联网＋”与传统城市建设思维的结合才行得通。近些年来，随着互联网的发展，我们的生活与网络产生很大的管理，物物互联成为必然趋势，物联网的发展，为城市管理等都做出很大的贡献。一系列“城市病”如期而至：交通拥挤、环境污染、居民健康受到威胁，给市民工作生活带来诸多不便，而移动物联网的应用则成为治理手段。从广东移动了解到，目前各大运营商正积极落实与各级政府签订的战略合作协议要求，物联网、云计算、大数据等新技术，将在智慧生活、智慧医疗、智能环保等多个领域推陈出新，实现未来城市低碳、可持续发展的目标，从而大大造福于民。探索运用物联网等新技术，加强城市的智慧管理，助力解决“城市病”等问题。 据悉，今年全国两会期间，有人大代表就建议把握“万物互联”的时代机遇，加快建设“城市物联网”，将传感设备置入到城市的基础设施中，采集交通、停车场、水文、空气、土壤、城市内涝风险等数据，有利于实现城市的智能管理，提前进行灾害预防，也为城市大数据应用提供基础，提升民生服务和城市管理水平，有效治理“城市病”。比如广东移动的“基于物联云平台的行业大数据服务”项目成功入选广东省2015年大数据应用示范项目。 城市照明可调光可巡视 目前，上海市路灯中心所管辖的路灯有50万盏，加上各个小区，城市照明系统存在巨大节能减排潜力。由复旦大学、上海市建交委合作的项目已着手尝试。信息科学与工程学院沈海平老师介绍，上海城市隧道、越江隧道将采用基于LED的智能照明技术。新技术在色温、眩光指标、照明方式、控制系统、节能标准上均有所突破，其中最为新颖的，莫过于调光、巡检功能。专家解释，调光功能将能精确照明亮度，最大限度实现节能；至于巡检，过去路灯坏了，需要人力一个个检查；而今路灯性能将在操作平台上自行显示，免去了不必要的人力投入。 有研究表明，新型技术(物联网、云计算等)与传统产业相结合形成的智能产业，有望为全球降低15％至35％的碳排放，而其自身付出的碳排放仅有2％。郑立荣表示，智能产业形成智慧城市的构架，解决了因资源枯竭导致的“城市病”，更能使城市服务能力最大化，让市民切实体会到科技带来的生活改变。 智能药箱当随身“护士站” 老龄化社会扑面而来，目前，我国许多大医院人满为患，医生病人均怨声载道。如此不低碳、不环保的模式，也能通过物联网来扭转。由信息科学与工程学院院长郑立荣教授领衔的团队，开发了智能药箱(iMedbox)技术。专家解释，新技术整合传感器信息，通过清理、压缩、分析数据，远程指导老年人、慢性病人的服药情况。对病人而言，智能药箱犹如随身“护士站”，它非但会提醒何时服药，更可将服药后的身体各项指标监测状况传回医生，实现全程监测。 小小的智能药箱，不过是智慧医疗一部分。专家补充，今后在物联网协助下的“泛在医疗理念”，更可突破医患供需不平衡的尴尬。所谓“泛在医疗”，即在任何时间、任何地点对任何人进行医疗护理服务。这一理念对空巢独居老人、偏远地区病人等群体都具有开创性意义。 除此而外，节能减排不仅关系到当代人的利益，而且关系到下一代。节能减排有很多问题必须要用新的机制来解决，不能单纯靠传统的来解决。如果用物联网来建设管理城市节能减排，就可以精确到量，精确到点，就可避免“大而概之”的事情，按上一个芯片能够感知绿色设施的能源利用、水资源消耗情况，同步调节这些指标，就能让生活变得更好。 再比如，海绵城市用了一些智慧手段，控制水量、控制管网，使更多的水转化成地下水，把水面和地下水沟通起来。这样城市就像海绵那样多储存水。还有，如果我们每一个屋顶都装上太阳能，可以产生两个三峡电站的发电量，通过非常简单的智能电网，使更多的人可以享受住宅不仅用电还可以发电的效益。 在江门市，气象部门在46个气象站安装物联网卡，可以通过4G网络实施监控气象情况变化。在佛山市，有停车场试点推出了智能收费系统，可以通过移动网络将传感器所采集的停车信息传输到管理平台，大大提高停车计时计费的准确性。在汕头，公交企业在公交车上安装物联网卡，调度部门可以实时掌握车辆的位置信息，已覆盖11条公交线路的120辆公交车。 结语： 事实已经证明，推动集约、智能、绿色、低碳，都离不开物联网，其中的基础就是城市里广泛建设的数字资本市场。中央城市工作会议指出，数字成果的平台是我们现代化城市管理的一个基础性数据共享。而数字管理是实现城市管制效能提高的一个基础。在这个基础上，大数据帮我们可直接找到城市问题的症结。在这个基础上，把传统的网络化、精细化城市管理，升级为以智能传感为基础的物联网管理，这样物联网、云计算、大数据累加在一起，就可科学实现城市的节能减排，让生活环境更美好。 智慧城市模式有单向性的，也有综合性的。我们应该从一些单向性的城市病治理，转向综合性的治理模式，把几个专题性的问题叠加起来，其效果肯定是“1＋1大于2”，这种效果只有依靠“互联网＋”和物联网，依靠大数据，才能办到。 本文转自d1net（转载）
2017-07-02

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册