- 浏览: 61502 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (117)
- RPC相关 (4)
- mvc_controller (3)
- mvc_model (3)
- maven (4)
- mvc_view (5)
- IO (2)
- 业务相关 (2)
- MQ (7)
- 搜索引擎 (3)
- zookeeper (2)
- 工具相关 (4)
- 编辑错误 (1)
- tomcat (1)
- 单元测试 (1)
- 负载均衡 (1)
- ubuntu (1)
- nginx (1)
- dubbo (2)
- 网络站点分发 (1)
- 电商-支付相关 (10)
- 电商订单业务相关 (3)
- Core java1 (3)
- Core Java (12)
- 多线程高并发(并发包/线程/锁) (10)
- 数据库+缓存 (17)
- springcloud (2)
- jvm (5)
- 日志相关 (1)
- 算法 (3)
- spring (2)
- 分布式一致性算法 (1)
最新评论
无界阻塞队列,
生产者:创建订单时,存入队列信息,包括最终时间,订单ID,
消费者:一个线程while循环,获取队列超时元素方法,当队列没有数据时,此方法阻塞(poll)。
服务器宕机,容灾能力,可写入mq。
基于redis实现超时任务调度
基于redis优雅的实现超时任务调度
现有方式,使用job任务轮询检索数据库,检索出符合条件的数据进行业务处理,但如果时间短且数据量大时,
1. 不断查询数据库,对数据库压力增加,影响数据库性能。
2.一次查询出上万条,导致内存溢出,即使分页取数据效率不高。
通过redis有序集合(sorted set)存放和处理数据。
基本思路是,生产者:创建数据到redis集合信息,添加元素zadd key score member[[score member]],其中scorre分数属性可用于排序,可存放最终时间(score)和标识ID(member);
消费者:开启一个线程while循环,获取redis有序集合,按顺序查询元素 zrange key start stop (withscores),集合为空时阻塞1000毫秒,集合不为空时,比较超时时间,最终删除符合条件元素zrem key member[member...],同时处理超时业务。
注意:
1. 消费者可能是集群,导致处理相同数据业务,而redis是单线程单进程的实现,
在删除元素时(zrem)根据得到的返回值来判断是否继续处理业务,很好的避免了此问题。
2. 不是所有while循环都消耗资源,把循环的对象合理应用与销毁,资源消耗会很小。
3. 此方案不限使用redis,MQ也可实现。
以下是审批流程超时发送消息为例进行说明,
创建审批时把超时时间戳和审批ID存入redis有序集合,如果审批有改动需同时处理redis对应元素,开启一线程监听已有审批集合数据,比较审批时间戳,如果是超时,删除redis有序集合元素,并根据审批ID封装消息数据发送消息。
1.解耦,分为生产者消费者,各自处理自己业务
2.可异常恢复,服务器宕机,容灾能力强
3.支持分布式/集群环境
4.不影响数据库性能
spring boot-使用redis的Keyspace Notifications实现定时任务队列:
https://blog.csdn.net/liuchuanhong1/article/details/70147149
分布式事务解决方案
分布式事务,业界难题,没有通用的解决方案,根据自己业务做出合理解决方案。
一键发房,添加发房记录失败,但实际成功,数据不一致。传统的事物基于ACID(原子性,一致性,隔离性,持久性),
但是在分布式事务中无法处理,在业界中没有
通用的解决方案,但是还有所有解决,
分布式事务BASE,BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性。
我们无法做到强一致性(AB同时成功,AB同时失败),但每个应用都可以根据自己业务特点,采用合适的方式
来系统达到最终一致性。
微服务架构下基于RabbitMQ实现事物一致性
微服务倡导将复杂的单体应用拆分为若干个功能简单的、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。然而始终绕不开的一个问题就是如何解决分布式架构系统中的事物问题,目前应用TCC是呼声最高,也是落地最多的一个方案。TCC方案其实是两阶段方案的一种改进,其将本地资源管理器的功能融入到了业务实现中。其将整个业务逻辑显示的分成了Try、Confirm、Cancel三部分。try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。通过这个过程不难发现其中很明显的2个不足:
1)开发工作量大:它将部分资源管理器的功能融入到每个服务的开发中,导致服务的每个接口都需要实现try、confirm、cancle,还需要实现事务协调器,开发量不只翻了一倍;
2)实现难度大:系统需要记录每个应用的服务调用链路.
本发明通过消息中间件(RabbitMQ)+本地事物保证上、下游应用数据操作的一致性。
基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息,收到消息后执行相应操作,执行成功后进行相应的ACK。本质上讲是将分布式事务转换为两个本地事务,然后依靠下游业务的重试机制达到最终一致性。相对TCC方案来讲,消息方案技术难度相对低,落地较容易。
以下以房客交易为例进行说明,交易基本流程是先存储交易信息,然后对房源状态及相关数据进行操作,两个操作必须在一个事务中。业务应用首先调用交易服务,存储成功后,交易服务会通过消息处理服务投递消息到RabbitMQ中。房服务从RabbitMQ收到消息后进行相关操作,如果执行成功会向消息处理服务发送通知。消息处理服务会实时监测消息是否超时,如果超时会重新投递到RabbitMQ中,以驱动房相关操作成功。如果操作执行失败后,房服务后续还会从MQ接收到相同的消息,需要多次重复执行,直到成功或者进行人工干预。此过程中房服务需要实现幂等。
1、开发工作量较小;
2、实现难度较低;
3、提高开发效率。
基于新型编码算法解决数据防盗爬系统
不足:
目前各大网站的数据防爬策略,多采用加密、混淆、token等方式,这些方式在很大程度上能够防止数据被爬取,但有一定的不足之处。比如加密、混淆的方式会造成url过长,不能清晰的体现业务;token方式增加了额外的系统开销,且可以通过刷token等方式对系统造成一定的侵害。
创新点:
本发明新型编码算法,通过多种复杂的混合算法,将有规律的数字ID加密转化为无规律的11位编码,编码之间无任何规律可循且无法被常规解密。
例如:
数字1,被加密为jzr13FqdpLk
数字2,被加密为1QFpcUgueU4
数字17,被加密为z_O0kIFslv0
明文与密文虽一一对应,但密文为无规律的随机字符组合,只有本发明所对应的解密算法才能进行正确快速的解密。当传入一个非本发明加密的一个恶意编码,其对应的解密算法会对该恶意编码进行拦截,让其根本到不了业务代码层面,极大程度的减少了数据被爬取的可能性,降低了恶意请求对业务的不良影响和对系统的冲击。
一、加密过程
1、将传入的数字明文转成固定长度(8位)的byte数组,如果数字明文大于100000000,则先对数字明文进行移位处理,再按照移位规则分别放入byte数组中(假设数组名为sourceBytes);
2、利用blowfish对称加密算法对sourceBytes数组中的每个数组元素数据进行加密(Blowfish是布鲁斯·施奈尔于1993年开发的区块加密算法,对称加密的一种),得到经过加密处理后的新的byte数组(假设数组名为encryptedBytes);
3、对加密后的encryptedBytes数组进行base64加密转码,得到经过加密转码后的新的byte数组(假设数组名为base64Bytes);
4、对转码后的base64Bytes进行二次处理,遍历数组元素,替换其中的易混字符和不安全字符;
5、将经过二次处理后的base64Bytes数据,转化为字符串密文,响应请求;
二、解密过程
1、对传入的密文进行还原处理,按照加密规则中的第4步,对应还原被替换掉的易混字符和不安全字符;
2、将经过还原处理后的密文进行base64解码,得到解码后的byte数组(假设数组名为sourceBytes);
3、利用blowfish对称加密算法对sourceBytes数组中的每个数组元素数据进行解密,得到经过解密处理后的新的byte数组(假设数组名为decryptedBytes);
4、将经过解密后的byte数组,转化为数字明文,响应请求;
好处:
1 不能被本发明外的算法解密,当出现大量恶意刷机请求时,解密算法会对请求进行拦截,极大程度的降低了对业务的侵害;
2 url简短明了,业务清晰;
3 没有类似token之类额外的系统开销;
生产者:创建订单时,存入队列信息,包括最终时间,订单ID,
消费者:一个线程while循环,获取队列超时元素方法,当队列没有数据时,此方法阻塞(poll)。
服务器宕机,容灾能力,可写入mq。
基于redis实现超时任务调度
基于redis优雅的实现超时任务调度
现有方式,使用job任务轮询检索数据库,检索出符合条件的数据进行业务处理,但如果时间短且数据量大时,
1. 不断查询数据库,对数据库压力增加,影响数据库性能。
2.一次查询出上万条,导致内存溢出,即使分页取数据效率不高。
通过redis有序集合(sorted set)存放和处理数据。
基本思路是,生产者:创建数据到redis集合信息,添加元素zadd key score member[[score member]],其中scorre分数属性可用于排序,可存放最终时间(score)和标识ID(member);
消费者:开启一个线程while循环,获取redis有序集合,按顺序查询元素 zrange key start stop (withscores),集合为空时阻塞1000毫秒,集合不为空时,比较超时时间,最终删除符合条件元素zrem key member[member...],同时处理超时业务。
注意:
1. 消费者可能是集群,导致处理相同数据业务,而redis是单线程单进程的实现,
在删除元素时(zrem)根据得到的返回值来判断是否继续处理业务,很好的避免了此问题。
2. 不是所有while循环都消耗资源,把循环的对象合理应用与销毁,资源消耗会很小。
3. 此方案不限使用redis,MQ也可实现。
以下是审批流程超时发送消息为例进行说明,
创建审批时把超时时间戳和审批ID存入redis有序集合,如果审批有改动需同时处理redis对应元素,开启一线程监听已有审批集合数据,比较审批时间戳,如果是超时,删除redis有序集合元素,并根据审批ID封装消息数据发送消息。
1.解耦,分为生产者消费者,各自处理自己业务
2.可异常恢复,服务器宕机,容灾能力强
3.支持分布式/集群环境
4.不影响数据库性能
spring boot-使用redis的Keyspace Notifications实现定时任务队列:
https://blog.csdn.net/liuchuanhong1/article/details/70147149
分布式事务解决方案
分布式事务,业界难题,没有通用的解决方案,根据自己业务做出合理解决方案。
一键发房,添加发房记录失败,但实际成功,数据不一致。传统的事物基于ACID(原子性,一致性,隔离性,持久性),
但是在分布式事务中无法处理,在业界中没有
通用的解决方案,但是还有所有解决,
分布式事务BASE,BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性。
我们无法做到强一致性(AB同时成功,AB同时失败),但每个应用都可以根据自己业务特点,采用合适的方式
来系统达到最终一致性。
微服务架构下基于RabbitMQ实现事物一致性
微服务倡导将复杂的单体应用拆分为若干个功能简单的、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。然而始终绕不开的一个问题就是如何解决分布式架构系统中的事物问题,目前应用TCC是呼声最高,也是落地最多的一个方案。TCC方案其实是两阶段方案的一种改进,其将本地资源管理器的功能融入到了业务实现中。其将整个业务逻辑显示的分成了Try、Confirm、Cancel三部分。try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。通过这个过程不难发现其中很明显的2个不足:
1)开发工作量大:它将部分资源管理器的功能融入到每个服务的开发中,导致服务的每个接口都需要实现try、confirm、cancle,还需要实现事务协调器,开发量不只翻了一倍;
2)实现难度大:系统需要记录每个应用的服务调用链路.
本发明通过消息中间件(RabbitMQ)+本地事物保证上、下游应用数据操作的一致性。
基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息,收到消息后执行相应操作,执行成功后进行相应的ACK。本质上讲是将分布式事务转换为两个本地事务,然后依靠下游业务的重试机制达到最终一致性。相对TCC方案来讲,消息方案技术难度相对低,落地较容易。
以下以房客交易为例进行说明,交易基本流程是先存储交易信息,然后对房源状态及相关数据进行操作,两个操作必须在一个事务中。业务应用首先调用交易服务,存储成功后,交易服务会通过消息处理服务投递消息到RabbitMQ中。房服务从RabbitMQ收到消息后进行相关操作,如果执行成功会向消息处理服务发送通知。消息处理服务会实时监测消息是否超时,如果超时会重新投递到RabbitMQ中,以驱动房相关操作成功。如果操作执行失败后,房服务后续还会从MQ接收到相同的消息,需要多次重复执行,直到成功或者进行人工干预。此过程中房服务需要实现幂等。
1、开发工作量较小;
2、实现难度较低;
3、提高开发效率。
基于新型编码算法解决数据防盗爬系统
不足:
目前各大网站的数据防爬策略,多采用加密、混淆、token等方式,这些方式在很大程度上能够防止数据被爬取,但有一定的不足之处。比如加密、混淆的方式会造成url过长,不能清晰的体现业务;token方式增加了额外的系统开销,且可以通过刷token等方式对系统造成一定的侵害。
创新点:
本发明新型编码算法,通过多种复杂的混合算法,将有规律的数字ID加密转化为无规律的11位编码,编码之间无任何规律可循且无法被常规解密。
例如:
数字1,被加密为jzr13FqdpLk
数字2,被加密为1QFpcUgueU4
数字17,被加密为z_O0kIFslv0
明文与密文虽一一对应,但密文为无规律的随机字符组合,只有本发明所对应的解密算法才能进行正确快速的解密。当传入一个非本发明加密的一个恶意编码,其对应的解密算法会对该恶意编码进行拦截,让其根本到不了业务代码层面,极大程度的减少了数据被爬取的可能性,降低了恶意请求对业务的不良影响和对系统的冲击。
一、加密过程
1、将传入的数字明文转成固定长度(8位)的byte数组,如果数字明文大于100000000,则先对数字明文进行移位处理,再按照移位规则分别放入byte数组中(假设数组名为sourceBytes);
2、利用blowfish对称加密算法对sourceBytes数组中的每个数组元素数据进行加密(Blowfish是布鲁斯·施奈尔于1993年开发的区块加密算法,对称加密的一种),得到经过加密处理后的新的byte数组(假设数组名为encryptedBytes);
3、对加密后的encryptedBytes数组进行base64加密转码,得到经过加密转码后的新的byte数组(假设数组名为base64Bytes);
4、对转码后的base64Bytes进行二次处理,遍历数组元素,替换其中的易混字符和不安全字符;
5、将经过二次处理后的base64Bytes数据,转化为字符串密文,响应请求;
二、解密过程
1、对传入的密文进行还原处理,按照加密规则中的第4步,对应还原被替换掉的易混字符和不安全字符;
2、将经过还原处理后的密文进行base64解码,得到解码后的byte数组(假设数组名为sourceBytes);
3、利用blowfish对称加密算法对sourceBytes数组中的每个数组元素数据进行解密,得到经过解密处理后的新的byte数组(假设数组名为decryptedBytes);
4、将经过解密后的byte数组,转化为数字明文,响应请求;
好处:
1 不能被本发明外的算法解密,当出现大量恶意刷机请求时,解密算法会对请求进行拦截,极大程度的降低了对业务的侵害;
2 url简短明了,业务清晰;
3 没有类似token之类额外的系统开销;
package com.pingan.haofang.agent.saas.api.common.utils.encry; /** * @require Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 * @author cgao * */ import java.nio.ByteBuffer; import java.nio.charset.Charset; import java.util.Arrays; import org.apache.log4j.Logger; /** * php/java -> 755.887552485/3184.7133757961783/3974.56279809221[useGlobals]/ * 25575.447570332482[includeLock] * * @author cgao fujie(copy from tudou) * @TODO i don't know if global.iv etc can thread safe */ public class IdEncrypterForjava { private static final Logger logger = Logger.getLogger(IdEncrypterForjava.class); private static final byte[] idCrypterSaltBytes = "H0w_many_r0ad_a_man_must_been_wa1k_d0wn, before_they_ca11_him_a_man.".getBytes(Charset.forName("ISO-8859-1")); private static Blowfish blowfish; static { blowfish = new Blowfish(Arrays.copyOf(idCrypterSaltBytes, 32), Arrays.copyOfRange(idCrypterSaltBytes, 32, 40)); } public static String encodeVid(int id) { try { byte[] sourceBytes = new byte[8]; if (id < 100000000) { int2bytes(sourceBytes, id); } else { sourceBytes[0] = (byte) ((id >> 24) & 0xFF); sourceBytes[1] = (byte) ((id >> 16) & 0xFF); sourceBytes[2] = (byte) ((id >> 8) & 0xFF); sourceBytes[3] = (byte) ((id) & 0xFF); sourceBytes[4] = Byte.MAX_VALUE; sourceBytes[5] = Byte.MAX_VALUE; sourceBytes[6] = Byte.MAX_VALUE; sourceBytes[7] = Byte.MAX_VALUE; } byte[] encryptedBytes = blowfish.encrypt(sourceBytes); char[] base64Chars = Base64.encode(encryptedBytes); int i; for (i = 0; i < base64Chars.length; i++) { if (base64Chars[i] == '=') { break; // = only appear at end, so i is the ending } else if (base64Chars[i] == '+') { base64Chars[i] = '-'; } else if (base64Chars[i] == '/') { base64Chars[i] = '_'; } } return new String(base64Chars, 0, i); } catch (Exception e) { logger.error("encode error, id=" + id, e); } return null; } public static int decodeVid(String code) { try { StringBuilder sb = new StringBuilder(code); int i = code.length(); while (i % 4 != 0) { sb.append('='); i++; } for (i = 0; i < sb.length(); i++) { if (sb.charAt(i) == '-') { sb.setCharAt(i, '+'); } else if (sb.charAt(i) == '_') { sb.setCharAt(i, '/'); } } byte[] sourceBytes = Base64.decode(sb.toString()); byte[] decryptedBytes = blowfish.decrypt(sourceBytes); if (decryptedBytes.length == 8 && decryptedBytes[7] == Byte.MAX_VALUE) { ByteBuffer bf = ByteBuffer.wrap(decryptedBytes); return bf.getInt(); } else { for (i = 0; i < decryptedBytes.length; i++) { if (decryptedBytes[i] == 0) { break; } } return bytes2int(decryptedBytes, 0, i); } } catch (Exception e) { logger.error("decode error, code=" + code, e); } return 0; } public static long decodeJuid(String encodeUid) throws NumberFormatException { if ((encodeUid != null) && (encodeUid.length() > 10) && (encodeUid.charAt(0) == '0')) { long time = Long.parseLong(encodeUid.substring(1, 10), 32); long rand = Long.parseLong(encodeUid.substring(10), 32); return (time * 100000L + rand); } return Long.parseLong(encodeUid, 32); } private static void int2bytes(byte[] bs, int v) { int l = 1; for (int vv = v; vv >= 10; l++) { vv /= 10; } for (int i = 1; i <= l; i++) { // down to up bs[l - i] = (byte) (v - v / 10 * 10 + 48); v = v / 10; } } private static int bytes2int(byte[] bs, int start, int l) { int r = 0; for (int i = 0; i < l; i++) { r += (int) (Math.pow(10, l - i - 1) * (bs[start + i] - 48)); // 48 = // 0, // 49 // = // 1 } return r; } }
相关推荐
专利法期限总结 摘抄: 一个月 公告送达 文件送交地址不清,无法邮寄的,可以通过公告的方式送达当事人。自公告之日起满1个月,该文件视为 已经送达。 细则4.5 专利无效补充证据 在专利复审委员会受理无效宣告...
在这样的背景下,对于有志于从事专利代理工作的实习生成长与学习来说,实习期间的总结尤为重要。本文将结合保险行业,深入探讨专利代理人实习的相关知识和实习体验,以及实习生在实习过程中获得的收获。 在保险领域...
【专利实习工作总结】 在专利实习过程中,我深入了解到专利代理工作的复杂性和重要性。实习初期,我在与当事人的沟通上存在不足,经理的反馈让我意识到建立自信和清晰的表达至关重要。通过不断练习,我逐渐提高了...
《专利代理实务分册》是一本深入探讨专利申请与代理实践的专业书籍,旨在帮助读者全面理解和掌握专利代理过程中的各个环节。书中的知识点丰富多样,涵盖了从专利的基本概念、分类到专利检索、撰写、审查、答辩及后期...
标题中的“2017年公司知识产权专利工作总结”表明了这是一个关于企业在2017年度在知识产权和专利工作方面的总结报告。在这个总结中,我们可能会看到公司在这一年里如何管理和保护其知识产权,包括申请、维护、许可和...
### 五、总结 通过Hadoop等大数据处理工具对专利数据集进行深入分析,不仅可以帮助我们更好地理解专利之间的关系和技术发展趋势,还可以为技术创新提供有力的支持。未来随着更多专利数据的开放,我们有望进一步挖掘...
### 个人总结:发明专利说明书参考模板 #### 技术领域 本发明主要聚焦于展览行业中对参展人员消费偏好的调查分析方法与系统,特别强调利用RFID(射频识别)技术自动化获取参展人员消费偏好信息。 #### 背景技术 ...
"专利代理人资格考试呕心沥血总结的实务模板.pdf" 本文档为专利代理人资格考试的实务模板,涵盖了专利法的主要内容,包括发明创造的定义、专利权的授予条件、新颖性、创造性和实用性等概念的解释,以及专利申请和...
总结来说,专利申请文件的撰写需要注意以下几点: 1. 独立权利要求应包含实现发明目的的必要技术特征,避免非必要特征,以确保保护范围清晰。 2. 从属权利要求的引用要准确,附加技术特征不应与独立权利要求冲突,...
总结,新专利法详解旨在全面解析我国专利制度的最新变化,帮助社会各界更好地理解和运用专利法,以保护创新成果,推动科技进步。对于专利申请人、持有者及法律工作者,深入学习和理解新专利法是维护自身权益、规避...
### 专利文献与检索知识点详解 #### 一、专利文献概述 **专利文献定义:** 专利文献主要指各国专利局发布的官方出版物,是记录发明创造的重要载体。 **专利文献类型:** - **发明专利说明书、实用新型说明书和...
大家在一起讨论本部门的核心技术逻辑,并进行总结归纳,例如广材助手团队梳理出三点:(1)《一种基于流文件转化的数据存储和查询方式》;(2)《一种将单个进程的界面同时嵌入多个进程并独立交互的方式》;(3)...
标准解法是基于历史专利总结出的常见问题解决模式;理想度法则强调追求系统功能的最优化,即在不增加资源消耗的情况下,提高性能或达到额外效果。 TRIZ的应用并不局限于大型企业,个人、中小企业甚至学校都可以通过...
总结起来,《2010专利法实施细则》是专利从业者、科研人员、企业法务以及所有关心知识产权保护的人士不可或缺的参考资料。通过《2010专利法实施细则语音版》的学习,可以更深入理解我国专利制度的运作机制,提高专利...
#### 四、总结 专利技术交底书是专利申请过程中不可或缺的一环,它不仅需要详细记录发明的技术细节,还需要清晰阐述发明相对于现有技术的优势所在。撰写时应确保内容的准确性、完整性和条理性,以提高专利申请的成功...
专利代理人资格考试呕心沥血总结的实务模板..pdf
根据提供的搜索结果,以下是对“全国各地级市专利申请与获得情况、绿色专利申请与获得情况数据2000-2021年”的社科数据内容总结:本数据集涵盖了2000年至2021年间全国各地级市的专利申请与获得情况,特别关注了绿色...
包含以下内容: 提交清单示例 版权新系统注册认证操作说明书 软著前期材料清单 授权书说明模板