系统需要生成根据业务类型生成流水号,每天从1开始生成,第二天会清零继续从0开始,流水号格式为: bizCode + date + incr  如:TT-2017112300001. 思路:利用Redis Incr 生成序列号,使用日期加业务编码作为组合Key,这样保证第二天生成的序列号又是从1开始. 由于我们业务量不是很大,这里在生成序列号之前先判断一下当前key是否存在,若不存在,设置此key过期时间为当天晚上23:59:59,避免生成很多过期的key. 整体设计流程思路如下: 关键代码如下:

最近又遇到需要根据日期生成流水号的业务,然后记录了几种生成方法,一个是通过java代码,一个是数据库的触发器,还有是通过redis.下面是代码: 通过java生成简易流水: /** * 通过日期和生成的流水号拼接 * @param maxCount 已经生成的个数 * @return */ public static String recountNew(int maxCount) { if (maxCount < 0) { return null; } //201707999 String st

分布式Id - redis方式   本篇分享内容是关于生成分布式Id的其中之一方案,除了redis方案之外还有如:数据库,雪花算法,mogodb(object_id也是数据库)等方案,对于redis来说是我们常用并接触比较多的,因此主要谈谈结合redis生成分布式id方案. 分布式Id设计流程图 基于redis的hash自动increment累加生成有序Id 定期删除无用hash列 分布式Id设计流程图(有点粗略) 基于redis的hash自动increment累加生成有序Id 使用redis方

@Component 生成组建 @ConfigurationProperties(prefix="redis") 读写redis配置文件 application.properties配置文件 #redis redis.host=127.0.0.1 redis.port=6379 redis.timeout=3 redis.password= redis.poolMaxTotal=10 redis.poolMaxIdle=10 redis.poolMaxWait=3 package co

对于MySql的全局ID(主键),我们一般采用自增整数列.程序生成GUID.单独的表作为ID生成器,这几种方案各有优劣,最终效率都不能说十分理想(尤其海量数据下),其实通过Redis的INCR可以很方便生成自增数,因为是操作缓存,生成的效率也不错. 插入数据库的主键也是连续增长的,配合索引,读取效率也很高. 下面是从Redis中获取新的自增数的代码: public sealed class Utils { private static readonly object sequence_locke

public class PrimaryKeyGenerator { private static readonly NedisClient client = new NedisClient(GetRedisConfig()); /// <summary> /// 获取当前Redis配置实例 /// </summary> /// <returns></returns> private static RedisConfiguration GetRedisCon

1. 原理     a. 从redis 获取需要表示的短链接的id( redis incr)     b. hashids 编码 id     c. openresty  conteent_by_lua_block 阶段显示数据   2. 安装以来的插件      a. lua hashdis  使用  luarocks 注意需要先安装lua 开发包    b. copy hashids lua 包 到 openresty 的lualib  方便调用    c. redis 安装   luaro

使用Redis來生成主鍵ID策略,這裡主要使用 RedisAtomicLong 類來實現主鍵生成策略.具體代碼如下: /** * @Description: 获取自增长值 * @param key key * @return */ public static Long getIncr(String key) { RedisAtomicLong redisAtomicLong = new RedisAtomicLong(key,redisTemplate.getConnectionFactory(

项目描述 最近做的一个项目有这么一个需求:需要生成一个唯一的11位的就餐码(类似于订单号的概念),就餐码的规则是:一共是11位的数字,前面6位是日期比如2019年07月20就是190720,后面五位是随机数且不能是自增的,不然容易让人看出一天的单量. 解决方案 五位随机数不能用随机生成的,不然可能不唯一,所以想到了预生成的方案: 采用redis 随机数生成 先生成10000~99999共9万个数(从1万开始是懒得再前面补0了),然后打乱分别 存入redis的list数据结构 90个key每个ke

/** * 订单编号生成规则 * 14位 = 6位时间 + 5位自增 + 3位ID * @param string $prefix 前缀: 默认为order * @param int $userId 用户ID: 默认为1 * @param int $startTime 开始的日期时间戳: 默认为0 * @param int $expiredAt 有效期: 默认为永久 * @return string */ public function getRedisOrderNum($prefix = 'o

环境依赖: //spingBoot <version>2.6.6</version> //jdk11 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupI

1.建表tablewater create table TABLEWATER ( tb_id INTEGER not null, vc_table_name ), num_water_no ) )vc_table_name 字段值为参数表table1.table2.... 2.存储过程实现 PROCEDURE get_waterno ( vtableName IN VARCHAR2, --表名 vcnt IN INT ,--流水号 vmax_waterno OUT number --最大流水号

CREATE OR REPLACE FUNCTION fn_no_make(v_type VARCHAR2, v_number_col VARCHAR2, v_table_name VARCHAR2)/* * 参数说明: * v_type: 编码前缀 * v_number_col:编码所在列名 * v_table_name:编码所在表名 */ RETURN VARCHAR2 IS v_old_no VARCHAR2(50); --原编码 v_old_num NUMBER; -- 原编码后五位编号

场景: 公司内部有个业务场景是后台审核之后需要生成一个流水号,规则是: 201807280001,201807280002,201807280003,后面四位依次递增,前面年月日取当前时间并且转换成yyyymmdd格式. 于是想到redis比较适合做这种,而且因为是基于内存操作,速度比较快,不占用数据库资源,于是通过搜集整理出代码如下: @Override public String generate(String bizCode) { //** 获取今天的日期:yyyyMMdd *//* St

例如流水号格式如下:XX201604120001,2位前缀加8位日期加4位流水号 首先各种搜索出现如下解决方案 public class SerialNoHelper { /// <summary> /// 生成流水号 /// </summary> /// <param name="serialno">从数据库读取最大的流水号</param> /// <returns></returns> public Strin

在实际的开发中,可能会有根据一定的规则生成流水号的需求(比如根据根据公司编码和日期生成4位流水号)我们可以把公司和日期联合起来作为一个业务编码,把这个业务编码和序列的值存储到数据库中,每次需要生成流水号的时候根据公司和日期联合起来生成的这个业务编码去数据库里边去查,若有记录的话就把记录的话就把对应的序列值返回,然后序列的值加一,若根据对应的业务编码查询不到相应的记录就把流水号对应的最小的值返回,然后在数据库中插入相应的记录 缺点:在集群环境下可能导致在两台服务器上生成的流水号一致的情况(解决方法

一般单机或者单数据库的项目可能规模比较小,适应的场景也比较有限,平台的访问量和业务量都较小,业务ID的生成方式比较原始但是够用,它并没有给这样的系统带来问题和瓶颈,所以这种情况下我们并没有对此给予太多的关注.但是对于大厂的那种大规模复杂业务.分布式高并发的应用场景,显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成,而且在分布式环境下这种方式已经无法满足业务的需求,不仅无法完成业务能力,业务ID生成的速度或者重复问题可能给系统带来严重的故障.所以这一次,我们看看大厂都是怎么分

本文就来讲一下Redis安装的方法和Redis生成主键的优点以及和其他几种方式生成主键的对比. 1,Redis安装首先将Redis的tar包拷贝到Linux下的根目录 然后解压到redis文件夹下:(先使用mkdir创建redis文件夹) 接下来就是解压tar包到redis目录下: 解压后的目录结构: 编译: 使用Make命令 安装: 安装好之后的目录:  6379 下的目录结构:(这个rdb文件时: redis database, 暂时不用管它, 重启后自动生成的) bin下的目录结构: 配置

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结.生成ID的方法有很多,适应不同的场景.需求以及性能要求.所以有些比较复杂的系统会有多个ID生成的策略.下面就介绍一些常见的ID生成策略. 1. 数据库自增长序列或字段 最常见的方式.利用数据库,全数据库唯一. 优点: 1)简单,代码方便,性能可以接受. 2)数字ID天然排序,对分页或者需要排序的结果很有帮助. 缺点: 1)不同数据库语法和实现不同,数据库迁移的时候或多数据库版本支持的时候需要处理. 2)在单个数据库或

在分布式系统下唯一id问题,就是id咋生成?比如分表分库,因为要是一个表分成多个表之后,每个表的id都是从1开始累加自增长,那是不对的.举个例子,一个表拆分为了2张表,每个表的id都从1开始累加,这个肯定有问题了!你的系统就没办法根据表主键来查询了,比如id = 10这个记录,在两个表里都有!所以此时就需要分布式架构下的全局唯一id生成的方案了,保证每个表内的某个id,全局唯一.全局唯一id主要有以下几种方案. 分布式ID的生成方案 1. UUID 算法的核心思想是结合机器的网卡.当地时间.一个