蚊章汇 - redis
type: channel
link: https://linuxcn.bwsl.wang/tag/redis/
items: 硬核观察 #534 B 站发布新项目让老动漫变高清
items: 硬核观察 | Redis Labs 最新一轮融资估值突破 20 亿美元
items: #新闻拍一拍# Redis 作者辞去 Redis 项目的领导者和维护者职务
items: 使用 Redis 和 Python 构建一个共享单车的应用程序
items: Streams：一个新的 Redis 通用数据结构
items: 并发服务器（五）：Redis 案例研究
items: 如何让网站不下线而从 Redis 2 迁移到 Redis 3
items: 大量 Redis 服务器存在 SSH 权限窃取风险
items: 开源新闻速递：逾 6000 Redis 服务器被取得 SSH 权限
items: 如何在 CentOS 7 上安装 Redis 服务器

硬核观察 #534 B 站发布新项目让老动漫变高清
type: item
date: 2022-02-01T19:55:00+08:00
description: B 站发布新项目让老动漫变高清B 站在 GitHub 发布了 Real-CUGAN 项目，可让老旧动漫画面变高清。据了解，Real-CUGAN 是一个使用百万级动漫数据进行训练的，结构与 Waifu2x 兼容的通用动漫图像超分辨率模型，支持 2x/3x/4x 倍超分辨率。从官方晒出的对比图来看，修复后的画面比原版要高清得多，即便是“上古画质”如《黑猫警长》等动漫也能实现高清修复，效果十分显著。但该项目并没有指定使用的开源许可证，仅仅只是公开了源代码。老王点评：“开源”值得鼓励，但是看来他们在“开源”之前没想好，这或许是 B 站在开源方面没有明确的管理和政策吧。一网站因通过谷歌字体泄露访问者的 IP 地址被德国法院罚款该网站通过在其网页上加入谷歌字体托管的字体，在未经授权和没有合法理由的情况下将身份不明的原告的 IP 地址传递给谷歌。而这违反了欧洲的《一般数据保护条例》（GDPR）。这种热链接对谷歌字体来说是正常的；这里的问题是，访问者显然没有允许他们的 IP 地址被共享。该网站被法院 罚以 110 美元，如果继续不正当使用谷歌字体，每次罚款 25 万欧元，或最多监禁 6 个月。大约有 5 千万个网站远程使用谷歌字体。老王点评：好吧，基于两个不用说的原因，国内的网站并不需要忧虑此事。Redis 7.0 即将迎来“重大性能优化”本周一，Redis 7.0 迎来了首个候选发布版本。其称有了“重大的性能优化”和其它功能改进，但也有些带来了一些向后兼容性问题。7.0 通过各种优化来“显著”节省了内存资源、降低写入时复制内存的开销、提升内存效率，改进 fsync 来避免大量的磁盘写入和优化延迟表现。老王点评：一个值得关注的版本，但是我觉得 Redis 已经不是那个曾经小而美的软件了。

硬核观察 | Redis Labs 最新一轮融资估值突破 20 亿美元
type: item
date: 2021-04-08T23:44:58+08:00
description: Redis Labs 最新一轮融资估值突破 20 亿美元这个流行的开源数据库背后的公司 Redis Labs 周三宣布完成 G 轮融资，获得 1.1 亿美元的融资，使其估值超过 20 亿美元。Redis Labs 成立于 2011 年，目前已净融资 3.47 亿美元。本轮融资后，较去年 8 月的融资后估值翻了一倍。Redis Labs 目前拥有超过 8000 家付费客户，其中包括 31% 的财富 100 强企业。在基础软件领域，几个开源企业都显得非常有活力，其公司估值也非常可观。特斯拉否认使用摄像头监控车主针对近日流传特斯拉通过车内摄像头监控车主的讨论，特斯拉周三回应称，驾驶室内的摄像头目前在北美以外的市场并没有激活；即使在美国，车主也可以自由选择是否开启使用。特斯拉官方微博账号表示，特斯拉用户使用的车辆不存在通过车内摄像头侵犯用户个人隐私的行为。所有中国市场上的特斯拉用户车辆均未开启车内摄像头，也不涉及 FSD Beta 的测试。用户被采集什么数据、数据存放在哪里和对数据的控制权，缺少足够的透明度，这是问题的症结所在。超 5 亿用户信息遭泄露，但 Facebook 并不打算通知相关用户上周，据报道，大量 Facebook 用户的电话号码及其他个人信息被公布于一个公共数据库中。随后 Facebook 承认，黑客通过同步联系人工具中的一个漏洞获取了 2019 年 9 月之前的用户数据，Facebook 已于在 2019 年修复了该漏洞。但 Facebook 表示，考虑到这不是用户可以自行修补的漏洞，而且这些用户的数据已经被公布于网络，因此决定不再专门通知相关用户。现在的互联网简直就是筛子，所有在网络上活动的人的个人信息，都被泄露了一遍又一遍。虽然说出现这样的问题也是 Facebook 所不乐见的，但是这样的反应态度也确实让网民心寒。

#新闻拍一拍# Redis 作者辞去 Redis 项目的领导者和维护者职务
type: item
date: 2020-07-01T21:28:44+08:00
description: Redis 作者辞去 Redis 项目的领导者和维护者职务Redis 作者 antirez 选择将 Redis 交给 Redis 社区打理，并邀请到了两位同事 Yossi Gottlieb 和 Oran Agra 继续维护 Redis 项目。而他将成为 Redis Labs 顾问委员会的一员，会为 Redis 的更多发展可能性输出自己的想法。antirez 说到，从本质上来讲，他宁愿以一个糟糕的艺术家身份而不是一名好程序员而被人记住。来源：开源中国拍一拍：更早之前，Python 之父已经潇洒地放下了 Python “仁慈独裁者”的身份。开源软件领袖也会老去，也会厌倦将一生都投入到一件看起来要做一辈子的事情当中。前两天 Linus 也表达了内核维护工作让他感到“无聊”，感慨内核社区的核心成员五十岁以下的年轻人比较少，而“年轻”一些的人还不能接过整个社区的管理。KDE 社区迁移至 Gitlab2019 年 11 月，KDE 社区宣布计划迁移至 Gitlab。目前，它已正式完成迁移计划的第一阶段，并加入了 GitLab 的开源计划。KDE 社区共同创建和维护了 200 多个应用程序和不计其数的插件，还包括 1000 多个存储库、80 多个 Qt 框架，以及超过 2600 个项目。在迁移过程中，KDE 面临的最大挑战是要处理的巨大数据量，以及如何将其集成到众多工具中。来源：开源中国拍一拍：这是一个艰巨的任务，而且看起来 GitLab 似乎比 GitHub 更自由一些。GnuCash 4.0 释出GNU 财务软件项目 GnuCash 在邮件列表上宣布释出最新的 GnuCash 4.0。新版引入了一个独立的可执行文件 gnucash-cli，用于命令行操作如更新账簿中的价格。来源：solidot

使用 Redis 和 Python 构建一个共享单车的应用程序
type: item
date: 2018-11-14T19:21:26+08:00
description: 学习如何使用 Redis 和 Python 构建一个位置感知的应用程序。我经常出差。但不是一个汽车狂热分子，所以当我有空闲时，我更喜欢在城市中散步或者骑单车。我参观过的许多城市都有共享单车系统，你可以租个单车用几个小时。大多数系统都有一个应用程序来帮助用户定位和租用他们的单车，但对于像我这样的用户来说，在一个地方可以获得可租赁的城市中所有单车的信息会更有帮助。为了解决这个问题并且展示开源的强大还有为 Web 应用程序添加位置感知的功能，我组合了可用的公开的共享单车数据、Python 编程语言以及开源的 Redis 内存数据结构服务，用来索引和查询地理空间数据。由此诞生的共享单车应用程序包含来自很多不同的共享系统的数据，包括纽约市的 Citi Bike 共享单车系统（LCTT 译注：Citi Bike 是纽约市的一个私营公共单车系统。在 2013 年 5 月 27 日正式营运，是美国最大的公共单车系统。Citi Bike 的名称有两层意思。Citi 是计划赞助商花旗银行（CitiBank）的名字。同时，Citi 和英文中“城市（city）”一词的读音相同）。它利用了花旗单车系统提供的 通用共享单车数据流 General Bikeshare Feed ，并利用其数据演示了一些使用 Redis 地理空间数据索引的功能。 花旗单车数据可按照 花旗单车数据许可协议 提供。通用共享单车数据流规范 通用共享单车数据流规范 General Bikeshare Feed Specification （GBFS）是由 北美共享单车协会 开发的 开放数据规范，旨在使地图程序和运输程序更容易的将共享单车系统添加到对应平台中。 目前世界上有 60 多个不同的共享系统使用该规范。Feed 流由几个简单的 JSON 数据文件组成，其中包含系统状态的信息。 Feed 流以一个顶级 JSON 文件开头，其引用了子数据流的 URL：{ "data": { "en": { "feeds": [ { "name": "system_information", "url": "https://gbfs.citibikenyc.com/gbfs/en/system_information.json" }, { "name": "station_information", "url": "https://gbfs.citibikenyc.com/gbfs/en/station_information.json" }, . . . ] } }, "last_updated": 1506370010, "ttl": 10 }第一步是使用 system_information 和 station_information 的数据将共享单车站的信息加载到 Redis 中。system_information 提供系统 ID，系统 ID 是一个简短编码，可用于为 Redis 键名创建命名空间。 GBFS 规范没有指定系统 ID 的格式，但确保它是全局唯一的。许多共享单车数据流使用诸如“coastbikeshare”，“boisegreenbike” 或者 “topekametro\_bikes” 这样的短名称作为系统 ID。其他的使用常见的有地理缩写，例如 NYC 或者 BA，并且使用通用唯一标识符（UUID）。 这个共享单车应用程序使用该标识符作为前缀来为指定系统构造唯一键。station_information 数据流提供组成整个系统的共享单车站的静态信息。车站由具有多个字段的 JSON 对象表示。车站对象中有几个必填字段，用于提供物理单车站的 ID、名称和位置。还有几个可选字段提供有用的信息，例如最近的十字路口、可接受的付款方式。这是共享单车应用程序这一部分的主要信息来源。建立数据库我编写了一个示例应用程序 loadstationdata.py，它模仿后端进程中从外部源加载数据时会发生什么。查找共享单车站从 GitHub 上 GBFS 仓库中的 systems.csv 文件开始加载共享单车数据。仓库中的 systems.csv 文件提供已注册的共享单车系统及可用的 GBFS 数据流的 发现 URL discovery URL 。 这个发现 URL 是处理共享单车信息的起点。load_station_data 程序获取系统文件中找到的每个发现 URL，并使用它来查找两个子数据流的 URL：系统信息和车站信息。 系统信息提供提供了一条关键信息：系统的唯一 ID。 （注意：系统 ID 也在 systems.csv 文件中提供，但文件中的某些标识符与数据流中的标识符不匹配，因此我总是从数据流中获取标识符。）系统上的详细信息，比如共享单车 URL、电话号码和电子邮件， 可以在程序的后续版…

Streams：一个新的 Redis 通用数据结构
type: item
date: 2018-07-30T05:47:00+08:00
description: 直到几个月以前，对于我来说，在消息传递的环境中， 流 streams 只是一个有趣且相对简单的概念。这个概念在 Kafka 流行之后，我主要研究它们在 Disque 案例中的应用，Disque 是一个消息队列，它将在 Redis 4.2 中被转换为 Redis 的一个模块。后来我决定让 Disque 都用 AP 消息（LCTT 译注：参见 CAP 定理），也就是说，它将在不需要客户端过多参与的情况下实现容错和可用性，这样一来，我更加确定地认为流的概念在那种情况下并不适用。然而在那时 Redis 有个问题，那就是缺省情况下导出数据结构并不轻松。它在 Redis 列表 list 、 有序集 sorted list 、 发布/订阅 Pub/Sub 功能之间有某些缺陷。你可以权衡使用这些工具对一系列消息或事件建模。有序集是内存消耗大户，那自然就不能对投递的相同消息进行一次又一次的建模，客户端不能阻塞新消息。因为有序集并不是一个序列化的数据结构，它是一个元素可以根据它们量的变化而移动的集合：所以它不像时序性的数据那样。列表有另外的问题，它在某些特定的用例中会产生类似的适用性问题：你无法浏览列表中间的内容，因为在那种情况下，访问时间是线性的。此外，没有任何指定输出的功能，列表上的阻塞操作仅为单个客户端提供单个元素。列表中没有固定的元素标识，也就是说，不能指定从哪个元素开始给我提供内容。对于一对多的工作任务，有发布/订阅机制，它在大多数情况下是非常好的，但是，对于某些不想 “即发即弃” fire-and-forget 的东西：保留一个历史是很重要的，不只是因为是断开之后会重新获得消息，也因为某些如时序性的消息列表，用范围查询浏览是非常重要的：比如在这 10 秒范围内温度读数是多少？我试图解决上述问题，我想规划一个通用的有序集合，并列入一个独特的、更灵活的数据结构，然而，我的设计尝试最终以生成一个比当前的数据结构更加矫揉造作的结果而告终。Redis 有个好处，它的数据结构导出更像自然的计算机科学的数据结构，而不是 “Salvatore 发明的 API”。因此，我最终停止了我的尝试，并且说，“ok，这是我们目前能提供的”，或许我会为发布/订阅增加一些历史信息，或者为列表访问增加一些更灵活的方式。然而，每次在会议上有用户对我说 “你如何在 Redis 中模拟时间系列” 或者类似的问题时，我的脸就绿了。起源在 Redis 4.0 中引入模块之后，用户开始考虑他们自己怎么去修复这些问题。其中一个用户 Timothy Downs 通过 IRC 和我说道：\<forkfork> 我计划给这个模块增加一个事务日志式的数据类型 —— 这意味着大量的订阅者可以在不导致 redis 内存激增的情况下做一些像发布/订阅那样的事情 \<forkfork> 订阅者持有他们在消息队列中的位置，而不是让 Redis 必须维护每个消费者的位置和为每个订阅者复制消息 他的思路启发了我。我想了几天，并且意识到这可能是我们马上同时解决上面所有问题的契机。我需要去重新构思 “日志” 的概念是什么。日志是个基本的编程元素，每个人都使用过它，因为它只是简单地以追加模式打开一个文件，并以一定的格式写入数据。然而 Redis 数据结构必须是抽象的。它们在内存中，并且我们使用内存并不是因为我们懒，而是因为使用一些指针，我们可以概念化数据结构并把它们抽象，以使它们摆脱明确的限制。例如，一般来说日志有几个问题：偏移不是逻辑化的，而是真实的字节偏移，如果你想要与条目插入的时间相关的逻辑偏移应该怎么办？我们有范围查询可用。同样，日志通常很难进行垃圾回收：在一个只能进行追加操作的数据结构中怎么去删除旧的元素？好吧，在我们理想的日志中，我们只需要说，我想要数字最大的那个条目，而旧的元素一个也不要，等等。当我从 Timothy 的想法中受到启发，去尝试着写一个规范的时候，我使用了 Redis 集群中的 radix 树去实现，优化了它内部的某些部分。这为实现一个有效利用空间的日志提供了基础，而且仍然有可能在 对数时间 logarithmic time 内访问范围。同时，我开始去读关于 Kafka 的流相关的内容以获得另外的灵感，它也非常适合我的设计，最后借鉴了 Kafka 消费组 consumer groups 的概念，并且再次针对 Redis 进行优化，以适用于 Redis 在内存中使用的情况。然而，该规范仅停留在纸面上，在一段时间后我几乎把它从头到尾重写了一遍，以便将我与别人讨论的所得到的许多建议一起增加到 Redis 升级中。我希望 Redis 流能成为对于时间序列有用的特性，而不仅是一个常见的事件和消息类的应用程序。让我们写一些代码吧从 Redis 大会回来后，整个夏天我都在实现一个叫 listpa…

并发服务器（五）：Redis 案例研究
type: item
date: 2018-03-08T03:31:28+08:00
description: 这是我写的并发网络服务器系列文章的第五部分。在前四部分中我们讨论了并发服务器的结构，这篇文章我们将去研究一个在生产系统中大量使用的服务器的案例—— Redis。Redis 是一个非常有魅力的项目，我关注它很久了。它最让我着迷的一点就是它的 C 源代码非常清晰。它也是一个高性能、大并发的内存数据库服务器的非常好的例子，它是研究网络并发服务器的一个非常好的案例，因此，我们不能错过这个好机会。我们来看看前四部分讨论的概念在真实世界中的应用程序。本系列的所有文章有：第一节 - 简介第二节 - 线程第三节 - 事件驱动第四节 - libuv第五节 - Redis 案例研究事件处理库Redis 最初发布于 2009 年，它最牛逼的一件事情大概就是它的速度 —— 它能够处理大量的并发客户端连接。需要特别指出的是，它是用一个单线程来完成的，而且还不对保存在内存中的数据使用任何复杂的锁或者同步机制。Redis 之所以如此牛逼是因为，它在给定的系统上使用了其可用的最快的事件循环，并将它们封装成由它实现的事件循环库（在 Linux 上是 epoll，在 BSD 上是 kqueue，等等）。这个库的名字叫做 ae。ae 使得编写一个快速服务器变得很容易，只要在它内部没有阻塞即可，而 Redis 则保证 注1 了这一点。在这里，我们的兴趣点主要是它对文件事件的支持 —— 当文件描述符（如网络套接字）有一些有趣的未决事情时将调用注册的回调函数。与 libuv 类似，ae 支持多路事件循环（参阅本系列的第三节和第四节）和不应该感到意外的 aeCreateFileEvent 信号：int aeCreateFileEvent(aeEventLoop *eventLoop, int fd, int mask, aeFileProc *proc, void *clientData); 它在 fd 上使用一个给定的事件循环，为新的文件事件注册一个回调（proc）函数。当使用的是 epoll 时，它将调用 epoll_ctl 在文件描述符上添加一个事件（可能是 EPOLLIN、EPOLLOUT、也或许两者都有，取决于 mask 参数）。ae 的 aeProcessEvents 功能是 “运行事件循环和发送回调函数”，它在底层调用了 epoll_wait。处理客户端请求我们通过跟踪 Redis 服务器代码来看一下，ae 如何为客户端事件注册回调函数的。initServer 启动时，通过注册一个回调函数来读取正在监听的套接字上的事件，通过使用回调函数 acceptTcpHandler 来调用 aeCreateFileEvent。当新的连接可用时，这个回调函数被调用。它调用 accept 注2 ，接下来是 acceptCommonHandler，它转而去调用 createClient 以初始化新客户端连接所需要的数据结构。createClient 的工作是去监听来自客户端的入站数据。它将套接字设置为非阻塞模式（一个异步事件循环中的关键因素）并使用 aeCreateFileEvent 去注册另外一个文件事件回调函数以读取事件 —— readQueryFromClient。每当客户端发送数据，这个函数将被事件循环调用。readQueryFromClient 就让我们期望的那样 —— 解析客户端命令和动作，并通过查询和/或操作数据来回复。因为客户端套接字是非阻塞的，所以这个函数必须能够处理 EAGAIN，以及部分数据；从客户端中读取的数据是累积在客户端专用的缓冲区中，而完整的查询可能被分割在回调函数的多个调用当中。将数据发送回客户端在前面的内容中，我说到了 readQueryFromClient 结束了发送给客户端的回复。这在逻辑上是正确的，因为 readQueryFromClient 准备要发送回复，但它不真正去做实质的发送 —— 因为这里并不能保证客户端套接字已经准备好写入/发送数据。我们必须为此使用事件循环机制。Redis 是这样做的，它注册一个 beforeSleep 函数，每次事件循环即将进入休眠时，调用它去等待套接字变得可以读取/写入。beforeSleep 做的其中一件事情就是调用 handleClientsWithPendingWrites。它的作用是通过调用 writeToClient 去尝试立即发送所有可用的回复；如果一些套接字不可用时，那么当套接字可用时，它将注册一个事件循环去调用 sendReplyToClient。这可以被看作为一种优化 —— 如果套接字可用于立即发送数据（一般是 TCP 套接字），这时并不需要注册事件 ——直接发送数据。因为套接字是非阻塞的，它从不会去阻塞循环。为什么 Redis 要实现它自己的事件库？在 第四节 中我们讨论了使用 li…

如何让网站不下线而从 Redis 2 迁移到 Redis 3
type: item
date: 2017-10-17T20:45:35+08:00
description: 我们在 Sky Betting＆Gaming 中使用 Redis 作为共享内存缓存，用于那些需要跨 API 服务器或者 Web 服务器鉴别令牌之类的操作。在 Core Tribe 内，它用来帮助处理日益庞大的登录数量，特别是在繁忙的时候，我们在一分钟内登录数量会超过 20,000 人。这在很大程度上适用于数据存放在大量服务器的情况下（在 SSO 令牌用于 70 台 Apache HTTPD 服务器的情况下）。我们最近着手升级 Redis 服务器，此升级旨在使用 Redis 3.2 提供的原生集群功能。这篇博客希望解释为什么我们要使用集群、我们遇到的问题以及我们的解决方案。在开始阶段（或至少在升级之前）我们的传统缓存中每个缓存都包括一对 Redis 服务器，使用 keepalive 确保始终有一个主节点监听 浮动 IP floating IP 地址。当出现问题时，这些服务器对需要很大的精力来进行管理，而故障模式有时是非常各种各样的。有时，只允许读取它所持有的数据，而不允许写入的从属节点却会得到浮动 IP 地址，这种问题是相对容易诊断的，但会让无论哪个程序试图使用该缓存时都很麻烦。新的应用程序因此，这种情况下，我们需要构建一个新的应用程序，一个使用 共享内存缓存 shared in-memory cache 的应用程序，但是我们不希望对该缓存进行迂回的故障切换过程。因此，我们的要求是共享的内存缓存，没有单点故障，可以使用尽可能少的人为干预来应对多种不同的故障模式，并且在事件恢复之后也能够在很少的人为干预下恢复，一个额外的要求是提高缓存的安全性，以减少数据泄露的范围（稍后再说）。当时 Redis Sentinel 看起来很有希望，并且有许多程序支持代理 Redis 连接，比如 twemproxy。这会导致还要安装其它很多组件，它应该有效，并且人际交互最少，但它复杂而需要运行大量的服务器和服务，并且相互通信。将会有大量的应用服务器与 twemproxy 进行通信，这会将它们的调用路由到合适的 Redis 主节点，twemproxy 将从 sentinal 集群获取主节点的信息，它将控制哪台 Redis 实例是主，哪台是从。这个设置是复杂的，而且仍有单点故障，它依赖于 twemproxy 来处理分片，来连接到正确的 Redis 实例。它具有对应用程序透明的优点，所以我们可以在理论上做到将现有的应用程序转移到这个 Redis 配置，而不用改变应用程序。但是我们要从头开始构建一个应用程序，所以迁移应用程序不是一个必需条件。幸运的是，这个时候，Redis 3.2 出来了，而且内置了原生集群，消除了对单一 sentinel 集群需要。它有一个更简单的设置，但 twemproxy 不支持 Redis 集群分片，它能为你分片数据，但是如果尝试在与分片不一致的集群中这样做会导致问题。有参考的指南可以使其匹配，但是集群可以自动改变形式，并改变分片的设置方式。它仍然有单点故障。正是在这一点上，我将永远感谢我的一位同事发现了一个 Node.js 的 Redis 的集群发现驱动程序，让我们完全放弃了 twemproxy。因此，我们能够自动分片数据，故障转移和故障恢复基本上是自动的。应用程序知道哪些节点存在，并且在写入数据时，如果写入错误的节点，集群将自动重定向该写入。这是被选的配置，这让我们共享的内存缓存相当健壮，可以没有干预地应付基本的故障模式。在测试期间，我们的确发现了一些缺陷。复制是在一个接一个节点的基础上进行的，因此如果我们丢失了一个主节点，那么它的从节点会成为一个单点故障，直到死去的节点恢复服务，也只有主节点对集群健康投票，所以如果我们一下失去太多主节点，那么集群无法自我恢复。但这比我们过去的好。向前进随着使用集群 Redis 配置的新程序，我们对于老式 Redis 实例的状态变得越来越不适应，但是新程序与现有程序的规模并不相同（超过 30GB 的内存专用于我们最大的老式 Redis 实例数据库）。因此，随着 Redis 集群在底层得到了证实，我们决定迁移老式的 Redis 实例到新的 Redis 集群中。由于我们有一个原生支持 Redis 集群的 Node.js Redis 驱动程序，因此我们开始将 Node.js 程序迁移到 Redis 集群。但是，如何将数十亿字节的数据从一个地方移动到另一个地方，而不会造成重大问题？特别是考虑到这些数据是认证令牌，所以如果它们错了，我们的终端用户将会被登出。一个选择是要求网站完全下线，将所有内容都指向新的 Redis 群集，并将数据迁移到其中，以希望获得最佳效果。另一个选择是切换到新集群，并强制所有用户再次登录。由于显而易见的原因，这些都不是非常合适的。我们决定采取的替代方法是将数据同时写入老式 Redis …

大量 Redis 服务器存在 SSH 权限窃取风险
type: item
date: 2016-07-08T18:49:39+08:00
description: 完全无视安全功能的 Redis 服务器自创建以来饱受各种安全风险的困扰，Risk Based Security (RBS) 最近发现了 6338 台受到侵入的 Redis 服务器。Redis 是一个在内存中以键值对方式存储数据的 NOSQL 数据库。据 DB-Engines 的统计数据，它在 2015 年度的数据库流行度位列第十，而在键值对数据库中排名第一。由于 Redis 以性能为第一考量，所以默认配置下该数据库没有任何的认证或其它的安全控制功能。Redis 服务器存在 SSH 密钥创建漏洞任何人只要知道你的 IP 地址和 Redis 的端口，就可以访问其中的任意内容。更糟糕的是，在 2015 年末，发现了一种攻击方式可以让任何人在你的 Redis 服务器上的 authorized\_keys 文件中存储 SSH 密钥——这意味着，攻击者将不需要任何密码即可取得 Redis 服务器上的 SSH 访问权限。而现在，至少有三万台没有任何验证措施的 Redis 服务器暴露在互联网上，据 RBS 研究人员的称，已经有 6338 台 Redis 被窃取了 SSH 权限。该公司在通过 Shodan 进行了非侵入式扫描之后得出了如上结论。RBS 的研究人员在分析了被入侵的服务器之后发现，它们上面存在着一个名为“crackit” 的 SSH 密钥，其关联的邮件地址 ryan@exploit.im 曾在之前的其它入侵事件中出现过。除了 ryan@exploit.im 这个地址出现过 5892 次之外，root@chickenmelone.chicken.com 和 root@dedi10243.hostsailor.com 也分别出现了 385 次和 211 次。除了“crackit” 之外，还有一些名为“crackit\_key”， “qwe” ，“ck” 和 “crack” 之类的密钥名。据 RBS 分析，这表明它们来自多个组织或个人。攻击者并不针对特定的 Redis 版本，任何版本都可能被黑这些被攻击的 Redis 服务器的版本多达 106 个，从早期的 1.2.0. 到最新的 3.2.1 都有。“从对这些数据的分析中得不到更进一步的结果，只能确认两件事，第一件事是这并非新出现的漏洞，第二是，有些服务器只是被侵入了，但是并没有被利用。”RBS 研究人员解释说。该公司建议系统管理员们升级其 Redis 服务器到最新的版本，并启用 3.2 版本新引入的“保护模式”。另外，不要将 Redis 服务器或者其它的数据库暴露在互联网上是最起码的安全准则。

开源新闻速递：逾 6000 Redis 服务器被取得 SSH 权限
type: item
date: 2016-07-08T18:07:27+08:00
description: 今日关注默认情况下， Redis 不进行任何验证即可访问，所以一般来说，Redis 服务器都会放置在内网或使用防火墙禁止外部访问。但现在至少有 30000 台 Redis 服务器暴露在公网上。可能有人觉得 Redis 上并无重要数据，暴露也不要紧。但是去年年底出现的一个安全攻击可以通过 Redis 创建 SSH 登录密钥，这就是说，存在安全缺陷的 Redis 服务器会导致主机上的 SSH 访问开放。目前据 RBS 的报告，有超过 6000 台的 Redis 服务器已经被攻击感染。请系统管理员们尽快升级到最新版本，并启用相应的保护措施。图文摘要Canonical 和 Pivotal 公司达成合作，将成为 Pivotal Cloud Foundry 云平台上的首选操作系统。Ubuntu 15.10 作为非 LTS 版本，只有九个月的支持期，它将在7月28日结束支持。如果你在 Ubuntu 或其它支持 Snap 软件包的系统上运行过 GUI 程序，你可能注意到一些应用的样式不能跟随系统主题。现在，Canonical 宣布即将推出新的 Snap 桌面启动器，可以使 GUI 应用的主题样式和桌面主题保持一致。

如何在 CentOS 7 上安装 Redis 服务器
type: item
date: 2015-12-10T21:45:00+08:00
description: 大家好，本文的主题是 Redis，我们将要在 CentOS 7 上安装它。编译源代码，安装二进制文件，创建、安装文件。在安装了它的组件之后，我们还会配置 redis ，就像配置操作系统参数一样，目标就是让 redis 运行的更加可靠和快速。Redis 服务器Redis 是一个开源的多平台数据存储软件，使用 ANSI C 编写，直接在内存使用数据集，这使得它得以实现非常高的效率。Redis 支持多种编程语言，包括 Lua, C, Java, Python, Perl, PHP 和其他很多语言。redis 的代码量很小，只有约3万行，它只做“很少”的事，但是做的很好。尽管是在内存里工作，但是数据持久化的保存还是有的，而redis 的可靠性就很高，同时也支持集群，这些可以很好的保证你的数据安全。构建 Redisredis 目前没有官方 RPM 安装包，我们需要从源代码编译，而为了要编译就需要安装 Make 和 GCC。如果没有安装过 GCC 和 Make，那么就使用 yum 安装。yum install gcc make 从官网下载 tar 压缩包。curl http://download.redis.io/releases/redis-3.0.4.tar.gz -o redis-3.0.4.tar.gz 解压缩。tar zxvf redis-3.0.4.tar.gz 进入解压后的目录。cd redis-3.0.4 使用Make 编译源文件。make 安装进入源文件的目录。cd src 复制 Redis 的服务器和客户端到 /usr/local/bin。cp redis-server redis-cli /usr/local/bin 最好也把 sentinel，benchmark 和 check 复制过去。cp redis-sentinel redis-benchmark redis-check-aof redis-check-dump /usr/local/bin 创建redis 配置文件夹。mkdir /etc/redis 在/var/lib/redis 下创建有效的保存数据的目录mkdir -p /var/lib/redis/6379 系统参数为了让 redis 正常工作需要配置一些内核参数。配置 vm.overcommit_memory 为1，这可以避免数据被截断，详情见此。sysctl -w vm.overcommit_memory=1 修改 backlog 连接数的最大值超过 redis.conf 中的 tcp-backlog 值，即默认值511。你可以在kernel.org 找到更多有关基于 sysctl 的 ip 网络隧道的信息。sysctl -w net.core.somaxconn=512 取消对透明巨页内存（transparent huge pages）的支持，因为这会造成 redis 使用过程产生延时和内存访问问题。echo never > /sys/kernel/mm/transparent_hugepage/enabled redis.confredis.conf 是 redis 的配置文件，然而你会看到这个文件的名字是 6379.conf ，而这个数字就是 redis 监听的网络端口。如果你想要运行超过一个的 redis 实例，推荐用这样的名字。复制示例的 redis.conf 到 /etc/redis/6379.conf。cp redis.conf /etc/redis/6379.conf 现在编辑这个文件并且配置参数。vi /etc/redis/6379.conf daemonize设置 daemonize 为 no，systemd 需要它运行在前台，否则 redis 会突然挂掉。daemonize no pidfile设置 pidfile 为 /var/run/redis_6379.pid。pidfile /var/run/redis_6379.pid port如果不准备用默认端口，可以修改。port 6379 loglevel设置日志级别。loglevel notice logfile修改日志文件路径。logfile /var/log/redis_6379.log dir设置目录为 /var/lib/redis/6379dir /var/lib/redis/6379 安全下面有几个可以提高安全性的操作。Unix sockets在很多情况下，客户端程序和服务器端程序运行在同一个机器上，所以不需要监听网络上的 socket。如果这和你的使用情况类似，你就可以使用 unix socket 替代网络 socket，为此你需要配置 port 为0，然后配置下面的选项来启用 unix socket。设置 u…