Redis

import lombok.extern.slf4j.Slf4j; import org.apache.commons.lang3.StringUtils; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Component; import javax.annotation.Resource; import java.util.concurrent.TimeUnit; /** * Redis分布式锁 */ @Component @Slf4j public class RedisLock { @Resource private StringRedisTemplate stringRedisTemplate; private static final long EXPIRE = 30 * 1000L; // 失效时间 private static final long TIMEOUT = 10 * 1000L; // 等待时间 /** * 分布式加锁 * @param key * @param value requestTime + expireTime * @return */ public boolean secKilllock

Redis数据库安装: 在ubuntu下: 1.下载数据库 wget http://download.redis.io/releases/redis-4.0.9.tar.gz [最后是版本,根据需要调整] 2.解压下载包,可以解压在当前目录,也可以指定目录 tar -zxvf redis-4.0.9.tar.gz tar -zxvf redis-4.0.9.tar.gz /指定目录 3.ls 查看解压目录,cd 进入目录 cd redis-4.0.9 4.执行 编译命令 make install 5.重启服务 /etc/.init.d/redis-server restart redis安装完毕: 配置文件目录 /etc/redis/redis.conf 输入redis-server,出现如下界面表示安装成功 进入命令行模式 redis-cli -h {host} -p{6379} 有疑问?欢迎留言 来源： oschina 链接： https://my.oschina.net/u/4274413/blog/4872257

前言 基于Redis使用分布式锁在当今已经不是什么新鲜事了。本篇文章主要是基于我们实际项目中因为redis分布式锁造成的事故分析及解决方案。 背景 ： 我们项目中的抢购订单采用的是分布式锁来解决的。有一次，运营做了一个飞天茅台的抢购活动，库存100瓶，但是却超卖了！要知道，这个地球上飞天茅台的稀缺性啊！！！事故定为P0级重大事故...只能坦然接受。整个项目组被扣绩效了~~事故发生后，CTO指名点姓让我带头冲锋来处理，好吧，冲~ 事故现场 经过一番了解后，得知这个抢购活动接口以前从来没有出现过这种情况，但是这次为什么会超卖呢？原因在于：之前的抢购商品都不是什么稀缺性商品，而这次活动居然是飞天茅台 ，通过埋点数据分析，各项数据基本都是成倍增长，活动热烈程度可想而知！话不多说，直接上核心代码，机密部分做了伪代码处理。。。 public SeckillActivityRequestVO seckillHandle(SeckillActivityRequestVO request) { SeckillActivityRequestVO response; String key = "key:" + request.getSeckillId; try { Boolean lockFlag = redisTemplate.opsForValue().setIfAbsent(key, "val",

Redis有一系列的命令，特点是以NX结尾，NX是Not eXists的缩写，如SETNX命令就应该理解为：SET if Not eXists。这系列的命令非常有用，这里讲使用SETNX来实现分布式锁。 用SETNX实现分布式锁 利用SETNX非常简单地实现分布式锁。例如：某客户端要获得一个名字foo的锁，客户端使用下面的命令进行获取： SETNX lock.foo <current Unix time + lock timeout + 1> 如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。 如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。 解决死锁 上面的锁定逻辑有一个问题：如果一个持有锁的客户端失败或崩溃了不能释放锁，该怎么解决？我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。 发生这种情况时，可不能简单的通过DEL来删除锁，然后再SETNX一次，当多个客户端检测到锁超时后都会尝试去释放它，这里就可能出现一个竞态条件,让我们模拟一下这个场景： C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。 C1 发送DEL lock

一、字符串 命令 说明 set key val [ ex seconds | px milliseconds] [ nx | xx ] 设置字符串的值 ex：秒级过期时间 px：毫秒级过期时间 nx：键不存在才能设置成功，用于添加 xx：键存在才能设置成功，用于编辑 setnx key val 键不存在才能设置成功，用于添加 setex key seconds val 键存在才能设置成功，用于编辑 mset [key val …] 批量设置键值 get key 获取值 mget [key …] 批量获取值 incr key 自增 值非整数返回错误 值是整数返回自增结果 键不存在按 0 自增返回 1 decr key 自减 值非整数返回错误 值是整数返回自减结果 键不存在按 0 自减返回 - 1 incrby key increment 自增指定增量 decrby key decrement 自减指定减量 incrbyfloat key increment 自增指定浮点数 append key val 给字符串尾部追加字符 strlen key 计算字符串长度 getset key val 设置新值并返回原值 setrange key offset val 设置指定位置的字符 getrange key start end 获取指定位置字符串 二、哈希 命令 说明 hset key

业务背景 友盟+消息推送U-Push日均消息下发量百亿级，其中筛选任务日均数十万，筛选设备每分钟峰值可达7亿+，本文将分享友盟+技术架构团队在长期生产实践中沉淀的筛选架构解决方案。 如何保证百亿级的下发量？ 友盟+U-Push筛选是Push产品的核心功能，其中实时筛选是面向推送要求较高的付费Pro用户提供的核心能力之一，实现了用户实时打标、筛选、分发、触达的功能。友盟+U-Push的设备识别以device_token为基准，为保证尽可能的触达我们留存了近期所有可能触达客户的device_token，以10亿真实设备为例，每个设备安装10个集成友盟+SDK的应用可以产生10个device_token，牵扯到硬件环境变动导致的device_token漂移问题，可能产生更多device_token。 （ 图1.1.1 友盟+U-Push业务数据流简图） 图1.1.2 友盟+U-Push功能清单 U-Push筛选架构概览 2.1 上下行两个核心链路 U-Push服务由两个关键链路组成，下行链路保证客户消息的触达，上行链路承载终端采数和与客户服务端的数据同步。其中下行链路主要分为任务调度、筛选中心，上行链路主要服务是多种收数通道（为兼容历史问题）和设备中心，上行通过设备中心实现跟下行桥接。 图2.1.1 友盟+U-Push筛选业务场景 在U-Push服务中，依照业务场景不同定义了多种任务类型

如何解决高并发秒杀的超卖问题 由秒杀引发的一个问题 秒杀最大的一个问题就是解决超卖的问题。 其中一种解决超卖如下方式： 1 update goods set num = num - 1 WHERE id = 1001 and num > 0 我们假设现在商品只剩下一件了，此时数据库中 num = 1； 但有100个线程同时读取到了这个 num = 1 ，所以100个线程都开始减库存了。 但你会最终会发觉， 其实只有一个线程减库存成功，其他99个线程全部失败。 为何？ 这就是MySQL中的排他锁起了作用。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存， 如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁 ，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 就是类似于我在执行update操作的时候，这一行是一个事务 (默认加了排他锁 )。 这一行不能被任何其他线程修改和读写 第二种解决超卖的方式如下 1 select version from goods WHERE id = 1001 2 update goods set num = num - 1 , version = version + 1 WHERE id = 1001 AND num > 0 AND version = @version (上面查到的version);

太赞了！Github上都没有的“网约车”项目！！！ 以下内容全部真实！绝对真名 绝对不艺名！（附介绍） 该项目是一款标准且已上线的“网约车”应用。符合我国交通部对网约车监管的技术要求。通过了交通部对网约车线上和线下能力认定。项目原型曾在杭州上线运行。 项目中核心功能包括：账户系统，订单系统，支付系统，地图引擎，派单引擎，消息系统等 网约车核心解决方案。 项目中完全采用微服务架构设计，应用了成熟的接口安全设计方案，采用分布式锁保证了分布式环境中的数据同步，用分布式事务解决了分布式环境中的数据一致性等。 前置技能 Git，Maven，Spring Boot，Spring Cloud，Redis，MySql ，RabbitMQ，ActiveMQ等。 讲师是谁？ 说明：通过学习该项目，巩固大家原来学过的Spring Cloud微服务相关的知识，并学会如何在实际项目中落地应用。白皮书+视频+预习资料+视频教程都是有的！ 免费获取方式： 三连文章，然后加小助理微信 mxj94670 ”即可免费领取！ 啥也不说了，上图... 视频内容 项目详图 项目架构图 工程结构 好了，到这里，整个项目介绍的也差不多了，白皮书+视频+预习资料+视频讲解有感兴趣的朋友：三连关注之后，然后扫描下方即可免费领取！ 来源： oschina 链接： https://my.oschina.net/u/4361024

Redis缓存加速群集 Redis缓存加速 -----master的具体配置-------- 安装redis 1.下载redis的安装包 [root@localhost ~]# mount.cfs //192.168.1.150/qq-Download /mnt [root@localhost ~]# cd /mnt 2.通过yum工具，安装编译工具 [root@localhost ~]# yum install gcc gcc-c++ make -y 3.解压redis软件包 tar xzvf redis-5.0.7.tar.gz -C /opt 4.编译且安装 cd /opt/redis-5.0.7/ make make PREFIX=/usr/local/redis install 5.开启服务,设置各类文件 cd /opt/redis-5.0.7/utils/ [root@localhost utils]# ./install_server.sh Welcome to the redis service installer This script will help you easily set up a running redis server Please select the redis port for this instance: [6379] Selecting

1、 Linux是类UNIX操作系统，是一个基于POSIX移植操作系统接口和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。 2、用于企业服务器、WEB网站平台、大数据、虚拟化、Android、超级计算机、云计算、物联网、人工智能等领域。 3、开源免费；迭代更新；性能稳定；安全性高； 多任务，多用户；多线程；多CPU； 耗资源少；内核小； 应用广泛； 入门简单。 4、企业服务器品牌及型号：DELL（大多数公司），HP，IBM，浪潮，联想 2014年-2016年DELL：（1U）R420,R430， R620,R630 （2U）R720,R730 HP：2U DL380 G7/G8 IBM：1U 3550/m3 ,3550/m5 2U 3650，4U 3850，8U 3950 5、服务器尺寸：1U=4.45cm 1U 2U 4U 6、服务器一般是双电源,双线AB路 7、一般企业服务器的CPU数量2-4颗，单颗CPU4核，内存16-256G（常见32G,64G）。做虚拟化的宿主机，CPU数量4-8颗，单颗CPU4核，内存48-128G,6-10个虚拟机。 8、常见服务器磁盘是3.5mm英寸，大部分机械硬盘，读取性能相比内存来说不高，硬盘接口：IDE，SCSI SATA SAS SSD，性能： SSD> SAS > SATA， 磁盘阵列卡RAID：整合多块硬盘，有冗余备份