Redis

更多内容，欢迎关注微信公众号：全菜工程师小辉。公众号回复关键词，领取免费学习资料。 在Redis集群中，让若干个Redis服务器去复制另一个Redis服务器，我们定义被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave），这种模式叫做主从复制模式。 > 数据流向是单向的，只能是从master到slave > 一个slave只能有一个master 主从复制的作用 为数据提供多个副本，实现高可用 实现读写分离（主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性） 主从复制的方式 命令slaveof。 优点：无需重启。缺点：不便于管理 // 命令行使用 slaveof ip port // 使用命令后自身数据会被清空，但取消slave只是停止复制，并不清空 修改配置。 优点：统一配置。缺点：需要重启 // 配置文件中配置 slaveof ip port slave-read-only yes //只允许从节点进行读操作 全量复制 用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很大的开销 全量复制过程： Redis内部会发出一个同步命令，刚开始是Psync命令，Psync ? -1表示要求master主机同步数据

Java技术栈 www.javastack.cn 打开网站看更多优质文章 在高并发、异步化等场景，线程池的运用可以说无处不在。 线程池从本质上来讲，即通过空间换取时间，因为线程的创建和销毁都是要消耗资源和时间的，对于大量使用线程的场景，使用池化管 理可以延迟线程的销毁，大大提高单个线程的复用能力，进一步提升整体性能。 今天遇到了一个比较典型的线上问题，刚好和线程池有关，另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点，同时整个调查思路可以借鉴，特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务，首先简单交代下大致的业务流程，方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置，简单理解：当用户点击一个广告后，会从C端发起一次实时扣费请求(CPC，按点击扣费模式)，扣费服务则承接了该动作的核心业务逻辑：包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右，我们收到了一个线上告警通知： 扣费服务的线程池任务队列大小远远超出了设定阈值，而且队列大小随着时间推移还在持续变大。详细告警内容如下： 相应的，我们的广告指标：点击数、收入等也出现了非常明显的下滑，几乎同时发出了业务告警通知。其中，点击数指标对应的曲线表现如下： 该线上故障发生在流量高峰期

centos 下编译安装php7.3的redis扩展 本文是基于 centos 下编译安装PHP7.3搭建PHP运行环境 编译安装版本，进行的redis的编译扩展安装方法整理。 下载redis扩展包以及解压 1 2 wget http://pecl.php.net/get/redis-4.2.0.tgz tar -xzvf redis-4.2.0.tgz -C /opt/module 进入解压后目录，编译安装 1 2 cd /opt/module/redis-4.2.0 /usr/local/php/bin/phpize 常见错误 1 2 3 4 5 Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF environment variable. Then, rerun this script. # 安装autoconf yum install autoconf 查找php-config 1 find / -name php-config 编译安装 1 2 ./configure --with-php-config=/usr/local/php/bin/php-config make & make install 配置php.ini，添加redis.so扩展 1 2 3

大家好，我是历小冰，今天来讲一下 Reids Cluster 的 Gossip 协议和集群操作，文章的思维导图如下所示。 集群模式和 Gossip 简介 对于数据存储领域，当数据量或者请求流量大到一定程度后，就必然会引入分布式 。比如 Redis，虽然其单机性能十分优秀，但是因为下列原因时，也不得不引入集群。 单机无法保证高可用，需要引入多实例来提供高可用性 单机能够提供高达 8W 左右的QPS，再高的QPS则需要引入多实例 单机能够支持的数据量有限，处理更多的数据需要引入多实例； 单机所处理的网络流量已经超过服务器的网卡的上限值，需要引入多实例来分流。 有集群，集群往往需要维护一定的元数据，比如实例的ip地址，缓存分片的 slots 信息等，所以需要一套分布式机制来维护元数据的一致性。这类机制一般有两个模式：分散式和集中式 分散式机制将元数据存储在部分或者所有节点上，不同节点之间进行不断的通信来维护元数据的变更和一致性。Redis Cluster，Consul 等都是该模式。 而集中式是将集群元数据集中存储在外部节点或者中间件上，比如 zookeeper。旧版本的 kafka 和 storm 等都是使用该模式。 两种模式各有优劣，具体如下表所示： 模式 优点 缺点 集中式 数据更新及时，时效好，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的外部节点中

前言 之前的博客中，redis已经安装成功了，单纯的在命令行输入命令来操作数据库是远远不能满足我们的需求的，我们需要使用java代码来操作redis，于是我们引入了jedis。 添加jar包 <!-- Redis客户端 --> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency> 单机版 每次使用都创建一个jedis连接 public void jedis() throws Exception{ //创建一个连接jedis对象，参数：host；port Jedis jedis = new Jedis("单机版redis的ip地址", 端口号); //直接使用jedis操作redis，所有jedis命令都对应一个方法 jedis.set("test", "sds"); String string = jedis.get("test"); System.out.println(string); //关闭连接 jedis.close(); } 使用连接池 public void jedisPool() throws Exception{ //创建一个连接池，两个参数：host和port JedisPool jedisPool = new JedisPool(

Redis网络模型是一个使用IO多路复用、单线程、非阻塞的模型。这个模型的优点在于单线程不用考虑加锁，如果在单核环境上可以将效率发挥到最大。它没有那么庞大，代码一共2000多行，因此比较容易分析，学长推荐。 另外 @浅墨 学长拿出了redis网络部分的代码，设计了应用层协议，添加了应用层buffer，定义了服务器类型，完成了一个基于Redis网络模型的简易网络库，我fork了一份，然后跟着学长的博客 Redis网络库源码分析 以及网上搜集的资料，把这部分的源码根据自己的理解分析了一下，添加了很多注释，扔到我的git上，大概了解了服务端的工作过程，分享出来以供大家参考与我后期的回顾。 附上链接： Redis网络库源码浅解 参考资料： 什么是 Event Loop？ 杨博东的博客 来源： oschina 链接： https://my.oschina.net/u/4267970/blog/4779343

前言 redis是常用的no-sql数据库，常用于缓存数据，同时，他也可以持久化数据。他是C语言开发的，所以安装的时候需要编译。 单机版redis yum install gcc-c++ （安装C语言编译环境） 安装 第一步：redis的源码包上传到linux系统（ 点击下载 ） 第二步： tar xzvf redis-3.0.0.tar.gz （ 解压缩redis ） 第三步： make （ 编译。需进入redis源码目录 ） 第四步： make install PREFIX=/usr/local/redis （ 安装redis到指定目录 ） PREFIX参数指定redis的安装目录。一般软件安装到/usr目录下 启动 ./redis-server （服务前端启动） ./redis-cli shutdown （服务关闭） ./redis-server redis.conf （服务后端启动-需执行以下操作） cp redis.conf /usr/local/redis/bin/ （ 将 redis源码redis-3.0.0中的redis.conf复制到安装目录的bin下 ） 修改该配置文件，将其中的daemonize no改为yes ./redis-cli -h ip地址 -p 端口 （连接客户端） ping （ 判断服务健康状态 ） redis集群 机制 (1

前言 我回来啦，前段时间忙得不可开交。这段时间终于能喘口气了，继续把之前挖的坑填起来。写完上一篇秒杀系统（四）：数据库与缓存双写一致性深入分析后，感觉文章深度一下子被我抬高了一些，现在构思新文章的时候，反而畏手畏脚，不敢随便写了。对于未来文章内容的想法，我写在了本文的末尾。 本文我们来聊聊秒杀系统中的订单异步处理。 本篇文章主要内容 为何我们需要对下订单采用异步处理 简单的订单异步处理实现 非异步与异步下单接口的性能对比 一个用户抢购体验更好的实现方式 前文回顾 零基础实现秒杀系统（一）：防止超卖 零基础实现秒杀系统（二）：令牌桶限流 + 再谈超卖 零基础实现秒杀系统（三）：抢购接口隐藏 + 单用户限制频率 零基础实现秒杀系统（四）：数据库与缓存双写一致性深入分析 零基础上手秒杀系统（五）：如何优雅的完成订单异步处理（本文） ... 项目源码 再也不用担心看完文章不会代码实现啦： https://github.com/qqxx6661/miaosha 我发现该仓库的star数不知不觉已经超过100啦。❞ 我努力将整个仓库的代码尽量做到整洁和可复用，在代码中我尽量做好每个方法的文档，并且尽量最小化方法的功能，比如下面这样： public interface StockService { /** * 查询库存：通过缓存查询库存 * 缓存命中：返回库存 * 缓存未命中

1.介绍 目标：打造一款不同于市场上的公开打卡 app 的产品 理念：通过监督和鼓励，和相同圈子的人一起互相鼓励、分享及监督，共同进步。 优点： 模板消息通知，网上基本通过小程序中逻辑层 JS 完成推送的请求，小打卡在通知方面采用服务器端异步任务推送，使用了高性能分布式内存队列系统 BEANSTALKD ，来实现模板消息的异步定时推送。 数据库方面，因为要实现每月、每周或者指定时间段的打卡排名系统这个功能，目前数据库单张数据表已经超过几十万条数据记录，通过数据库查询排名统计不可行。这里需要用到 Redis 高性能数据库来缓存数据，并采用 Redis 的 zset 有序集合来进行不同方面的排序和查询 2.功能模块： 3.前端设计： 3.1首页交互设计 点击头像 会toast登陆成功 创建一个新的打卡按钮跳转至新建打卡页 点击我管理的打卡的回收箱在打卡旁边生成删除、取消按钮并隐藏打卡/已打卡按钮，点击取消按钮隐藏删除、取消按钮并恢复打卡、已打卡按钮，再次点击回收箱隐藏删除、取消按钮并恢复打卡/已打卡按钮 点击我管理的打卡列表/我参加的打卡/打卡按钮 跳转至 打卡详情页 打卡按钮打卡成功后变成“已打卡”并灰化 3.2新建打卡页交互设计 可以输入活动标题 开始结束时间为两个选项，点指定开始结束日期时会在下面显示 出开始日期：日期选择器&结束日期：日期选择器 点击开始报名费，弹窗提示

java编程思想 java并发编程实战 深入理解java虚拟机 函数式编程思维 tcp/ip详解 鸟哥的linux私房菜 spring mvc ＋mybatis开发从入门到精通 spring技术内幕 elasticsearch服务器开发 有坑 直接看文档 redis入门指南 (redis开发与运维 设计与实现) 分布式、集群、SOA、RPC、微服务、容器化、Docker 0基础，有人能推荐一下java编程思想的前置书籍/视频吗 java核心技术 今天去读书馆借了一本java 并发编程实战。结果直接看懵圈。建议还是要看看其他高并发编程视频。看了前几章引起高度不适。 2019-03-04 14:41 1 回复 二葱 没有操作系统原理基础，看不懂正常 2019-05-14 23:53 回复 热爱学习的林同学 看之前，最好看一看我写的并发编程基础博客https://clarence1993.github.io/ 2019-03-04 15:19 来源： oschina 链接： https://my.oschina.net/u/4349448/blog/3447962