Redis

一、安装Nginx #可通过ansible-doc yum 查看对应的帮助文档 [root@Ansible ~]# ansible test -m command -a "wget -O /etc/yum.repos.d/epel.repo" #下载epel源 [root@Ansible ~]# ansible test -m command -a "yum clean all" -u cedar -b [root@Ansible ~]# ansible test -m command -a "yum makecache" -u cedar -b [root@Ansible ~]# ansible test -m command -a "yum info nginx" -u cedar -b [root@Ansible ~]# ansible test -m yum -a "name=nginx state=present" -u cedar -b 10.3.153.8 | CHANGED => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": true, "changes": { "installed": [ "nginx" ] }, [root

通常情况下，Pod分配到哪些Node是不需要管理员操心的，这个过程会由scheduler自动实现。但有时，我们需要指定一些调度的限制，例如某些应用应该跑在具有SSD存储的节点上，有些应用应该跑在同一个节点上等等。 nodeSelector ： 首先我们为Node规划标签，然后在创建部署的时候，通过使用nodeSelector标签来指定Pod运行在哪些节点上。 亲和性（Affinity ）与反亲和性（AntiAffinity）： 亲和性：应用A与应用B两个应用频繁交互，所以有必要利用亲和性让两个应用的尽可能的靠近，甚至在一个node上，以减少因网络通信而带来的性能损耗。 反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，以提高HA。 包含：nodeAffinity（主机亲和性），podAffinity（POD亲和性）以及podAntiAffinity（POD反亲和性） 策略名称 匹配目标 支持的操作符 支持拓扑域 设计目标 nodeAffinity 主机标签 In,NotIn,Exists,DoesNotExist,Gt,Lt 不支持 决定Pod可以部署在哪些主机上 podAffinity Pod标签 In，NotIn，Exists，DoesNotExist 支持 决定Pod可以和哪些Pod部署在同一拓扑域 PodAntiAffinity

文章目录 业务场景 需求分析 设计思路 打乱题目顺序 数据都存储在本地 基于Mysql的系统设计 生成随机题目 记录用户答题结果 排行榜的刷新 交卷操作 基于Redis的系统设计 生成随机题目 记录用户答题结果 排行版的刷新 交卷操作 日志记录 压力测试 业务场景 100道不定项选择题，不同考生的题目顺序不一样 200位考生在规定时间同时开始和结束答题 考试开始后可以查看题目列表，不一定要按照顺序作答，已作答的题目可以修改，最终分数以交卷时的分数为准 在考场后台的办公室中可以实时刷新分数的排行榜 考试环境为学校的机房，网络环境为局域网 考试题目为文学类知识竞赛，考生准考证号和身份证号分别作为用户名和密码 需求分析 1、为了避免相互抄袭，不同考生的题目顺序需要不一样，这里需要打乱题目的顺序。 2、考试开始作答的时间可能不同，但是都要在统一的时间截止答题，这就要求考生的机器需要统一时间，能够在考试结束后自动提交。 3、在考试过程中要能够查看分数排行版，这里可以在考生每回答或者更新题目的时候都去刷新排行榜，或者在管理段定时刷新的时候再去计算所有考试的分数和排行榜情况。 4、考试环境为本地局域网，考试过程中有监考老师进行巡逻，并且考试群体大多不具备计算机知识，这里可以基本排除考生进行抓包后主动调用接口的场景。 设计思路 打乱题目顺序 1、使用mysql的随机排序方法， ORDER BY

最近看到redis4支持内存碎片清理了, 之前一直期待有这么一个功能, 因为之前遇到内存碎片的解决办法就是重启, 现在终于有了优雅的解决方案.\^o^/, 这个功能其实oranagra 在2017年1月1日已经提交pr了, 相关地址: https://github.com/antirez/redis/pull/3720 版本说明: Redis 4.0-RC3 以上版本才支持的 需要使用jemalloc作为内存分配器(默认的) 功能介绍: 支持在运行期进行自动内存碎片清理 (config set activedefrag yes) 支持通过命令 memory purge 进行清理(与自动清理区域不同) 功能验证流程: (1) 首先需要拉取4.0-RC3之后的版本代码, 编译 (2) 启动时限定内存大小为1g并启动lru, 命令如下: ./src/redis-server --maxmemory 1gb --maxmemory-policy allkeys-lru --activedefrag no --port 6383 (3) 构造大量数据并导致lru, 这样可以触发内存碎片, 命令如下: redis-cli -p 6383 debug populate 7000000 asdf 150 (4) 查看当前的内存使用情况, 会发现有200多万的数据被清理掉了 $ redis-cli

当Redis中清理了大量的Key之后原先Redis申请的内存（used_memory_rss）将继续持有而不会释放，此时查看内存信息将会看到存在大量的内存碎片。那么，Redis的内存碎片可以清理么，该如何清理呢？ 翻看了Redis的相关资料发现，Redis4版本之后开始支持内存碎片的清理，于是进行了一次测试，内容如下： 1. 搭建Redis 搭建一个Redis，版本为4.0.14.搭建步骤参考历史博文或微信公众号，步骤相对简单，没有太多幺蛾子，很快便可以搭建成功。 2. 插入一堆Key,使其内存占用很大 可以批量写一个循环，插入大量key。 3. 删除90%以上的key 循环删除key或在创建key时设置过期时间，待key删除或过期之后，可以查看内存的情况。 127 .0 .0 .1 :6379 > info memory # Memory used_memory :137040696 used_memory_human :130.69M used_memory_rss :11705876480 used_memory_rss_human :10.90G used_memory_peak :12091169848 used_memory_peak_human :11.26G used_memory_peak_perc :1.13 % used_memory_overhead

碎片监控 prometheus监控项 监控项 描述 阈值 redis_memory_used_rss_bytes os分配给redis的内存 redis_memory_used_bytes redis存储数据实际使用内存 redis_memory_used_rss_bytes/redis_memory_used_bytes >1.5 info memory 命令 127.0.0.1:7000> info memory # Memory used_memory:276755496 used_memory_rss:277745664 mem_fragmentation_ratio:1.00 mem_fragmentation_bytes:1031192 碎片整理 通过碎片整理将不连续的空闲内存，经过数据的拷贝迁移，实现空闲内存的合并、连续； 相关配置参数： 参数 默认值 描述 activedefrag no 是否开启碎片清理 active-defrag-ignore-bytes 100mb 当超过值时进行碎片清理 active-defrag-threshold-lower 10 内存碎片所占比例超过10%时进行碎片清理 active-defrag-cycle-min 1 碎片清理所用CPU时间比例不低于配置值 active-defrag-cycle-max 25

前言： 秒杀系统相信很多人见过，比如京东或者淘宝的秒杀，小米手机的秒杀。 那么秒杀系统的后台是如何实现的呢？我们如何设计一个秒杀系统呢？对于秒杀系统应该考虑哪些问题？如何设计出健壮的秒杀系统？本期我们就来探讨一下这个问题： 一：秒杀应该考虑哪些问题 1.1：超卖问题 分析秒杀的业务场景，最重要的有一点就是超卖问题，假如备货只有100个，但是最终超卖了200，一般来讲秒杀系统的价格都比较低，如果超卖将严重影响公司的财产利益，因此首当其冲的就是 解决商品的超卖问题 。 1.2：高并发 秒杀具有时间短、并发量大的特点，秒杀持续时间只有几分钟，而一般公司都为了制造轰动效应，会以极低的价格来吸引用户，因此参与抢购的用户会非常的多。 短时间内会有大量请求涌进来，后端如何 防止并发过高造成缓存击穿或者失效 ，击垮数据库都是需要考虑的问题。 1.3：接口防刷 现在的秒杀大多都会出来针对秒杀对应的软件，这类软件会模拟不断向后台服务器发起请求，一秒几百次都是很常见的，如何 防止 这类软件的 重复无效请求 ，防止不断发起的请求也是需要我们针对性考虑的 1.4：秒杀url 对于普通用户来讲，看到的只是一个比较简单的秒杀页面，在未达到规定时间，秒杀按钮是灰色的，一旦到达规定时间，灰色按钮变成可点击状态。这部分是针对小白用户的 如果是稍微有点电脑功底的用户，会通过F12看浏览器的network看到秒杀的url

为什么你写的sql查询慢？为什么你建的索引常失效？通过本章内容，你将学会MySQL性能下降的原因，索引的简介，索引创建的原则，explain命令的使用，以及explain输出字段的意义。助你了解索引，分析索引，使用索引，从而写出更高性能的sql语句。还在等啥子？卷起袖子就是干！ 案例分析 我们先简单了解一下 非关系型数据库 和 关系型数据库 的区别。 MongoDB是NoSQL中的一种。NoSQL的全称是Not only SQL，非关系型数据库。它的特点是 性能高 ， 扩张性强 ， 模式灵活 ，在高并发场景表现得尤为突出。但目前它还只是关系型数据库的补充，它在数据的一致性，数据的安全性，查询的复杂性问题上和关系型数据库还存在一定差距。 MySQL是关系性数据库中的一种， 查询功能强 ， 数据一致性高 ， 数据安全性高 ， 支持二级索引 。但性能方面稍逊与MongoDB，特别是百万级别以上的数据，很容易出现查询慢的现象。这时候需要分析查询慢的原因，一般情况下是程序员sql写的烂，或者是没有键索引，或者是索引失效等原因导致的。 公司ERP系统数据库主要是MongoDB（最接近关系型数据的NoSQL），其次是Redis，MySQL只占很少的部分。现在又重新使用MySQL，归功于阿里巴巴的奇门系统和聚石塔系统。考虑到订单数量已经是百万级以上，对MySQL的性能分析也就显得格外重要。

Kafka 简介 Apache Kafka 是一个分布式发布-订阅消息系统。是大数据领域消息队列中唯一的王者。最初由 linkedin 公司使用 scala 语言开发，在2010年贡献给了Apache基金会并成为顶级开源项目。至今已有十余年，仍然是大数据领域不可或缺的并且是越来越重要的一个组件。 Kafka 适合离线和在线消息，消息保留在磁盘上，并在集群内复制以防止数据丢失。kafka构建在zookeeper同步服务之上。它与 Flink 和 Spark 有非常好的集成，应用于实时流式数据分析。 Kafka特点： 可靠性：具有副本及容错机制。 可扩展性：kafka无需停机即可扩展节点及节点上线。 持久性：数据存储到磁盘上，持久性保存。 性能：kafka具有高吞吐量。达到TB级的数据，也有非常稳定的性能。 速度快：顺序写入和零拷贝技术使得kafka延迟控制在毫秒级。 Kafka 底层原理 先看下 Kafka 系统的架构 Kafka 架构 kafka支持消息持久化，消费端是主动拉取数据，消费状态和订阅关系由客户端负责维护， 消息消费完后，不会立即删除，会保留历史消息 。因此支持多订阅时，消息只会存储一份就可以。 broker ：kafka集群中包含一个或者多个服务实例（节点），这种服务实例被称为broker（一个broker就是一个节点/一个服务器）； topic

现在spring boot越来越重，每次要测试个什么东西必须要启动boot然后调用controller或者用boot test写单元测试，这两种我个人觉得都比较麻烦；我这边平常测试mongodb和redis处理都是直接写main代码进行测试，为了使用到spring提供的template类，我们需要自己初始化mongo和redis的客户端连接： mongodb连接初始化： import com.mongodb.MongoClient; import com.mongodb.MongoCredential; import com.mongodb.ServerAddress; import org.springframework.data.mongodb.core.MongoTemplate; import org.springframework.data.mongodb.core.SimpleMongoDbFactory; import org.springframework.data.mongodb.core.convert.DbRefResolver; import org.springframework.data.mongodb.core.convert.DefaultDbRefResolver; import org.springframework.data.mongodb