个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
https://segmentfault.com/a/1190000042971576
GeoHash原理以及代码实现_geohash编码-CSDN博客
GeoHash代码实现--java_geohash java代码示例-CSDN博客
Geohash是一种用于标识地理位置的编码方法。它将经纬度坐标转换为一个简短的字符串，这个字符串可以用来表示地球上的任意位置。Geohash的特点是，编码的长度越长，表示的位置就越精确；反之，编码越短，则表示的位置范围就越大。
接下来我们来一起探究一下这是个什么东西，有什么用？
参考的文章讲的也是非常不错，这里就啰嗦整理一下，并引申一下了。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
开篇先道个歉吧，因为大概会让很多人失望了，这次开源仅仅是开源，不是发版，也就是说开源并非非完全体，仅仅是开放源码。如果说1是发版，就算放低一些要求，现在只可能只算是0.2左右，还有很多很多很多事情要做。
开源地址：https://github.com/wnhyang/coolGuard
关注公众号，发送关键字“coolGuard”获取相关文档，但文档也还在编写中😂。
wnhyang邀请你加入语雀，注册后在会员信息页填写邀请码 WFC374 即可领取 30 天语雀会员。前往注册：https://www.yuque.com/about
为什么要选择10.24这个时间？因为1024比较浪漫！
我编的，其实是因为开源license要到期了😂
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
前面已经发了很多关于风控系统的一些文章，是比较零碎的，这也是我知道的，但在边构思边实践时是这样的。
从0到1中还有很多0.0001、0.0023424、0.1243，这些都是不可忽视，他们也是成长的一部分啊！
这里提前预告一下（毕竟有人看不到文末），下周大概是10.24会将这段时间关于风控系统的实践项目开源，具体信息请期待下一篇文章吧！
好了，开始本篇“风控系统之规则重复触发”。
风控系统包含如下这些内容，本篇讨论的归属于“反馈与自适应学习”之中。
1、数据处理与分析
2、规则引擎
3、机器学习
4、实时计算
5、决策树与图算法
6、系统集成与api
7、反馈与自适应学习
8、安全
9、可扩展
10、合规与监管
11、用户体验
当你长大了，故乡只有冬，再无春夏秋！
小学，每天都回家；初中、高中，一周一次；大学，半年1-2次；工作了，一年一次，而且每次都是在春节的冬季，相信有在北方小县城下生活过的朋友都有体会过北方萧瑟肃杀的冬季，所以这次趁着国庆，这个夏去秋来的时节去看看这段时间家里会不会有些不一样。但是，不出意外，一样的破败，可能是大城市到小县城到农村的再到农村的反差，又或是我真的变了，“清高了”！
接下来从几个角度讲一下吧！个人所见所闻的纯主观感受。
不得不说，这几年是有些变化的。
去年整个县都在改造，很多马路开膛破肚，修缮水管，如今用的是南水北调的水。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
在Sa-Token最新的v1.39.0版本的更新日志中有这么一句话
核心：
正巧最近有看一个关于鉴权的东西，顺便看一下吧！
目标：对于后端开放的api进行鉴权。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
默认你已经看过之前那篇风控系统指标计算/特征提取分析与实现01，Redis、Zset、模版方法。
其中已经介绍了如何利用redis的zset结构完成指标计算，为了方便这篇文章的介绍，还是在正式开始本篇之前回顾一下。
zset是redis中的一种数据结构，表示有序集合，正因此我们可以利用其做时间窗口来计算指标，value为事件标识，score为事件时间戳。
如下图表示次数、关联、求和类型各两条指标在时间窗口下随着时间分布，其中的黑点也就是事件，散列且线性的分布在时间窗口中。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
一天，小明在风控管理台查看事件数据时，发现一笔决策结果为“拒绝”❌的交易事件，小明点开事件详情发现其触发了一条“24小时内向不同陌生账户转账超过30w”的规则，规则设置的处置方式是“拒绝”❌。小明通过策略规则却查不到那条“24小时内向不同陌生账户转账超过30w”的规则，经确认原来是这条规则在此交易触发后一段时间内被修改了，已经不知道当时是如何配置的！？
这该怎么办？
我们要知道风控等其他系统都需要对于配置实时生效，所以使用了规则引擎，规则引擎具有实时生效优雅热刷新的特性，但也因此，如果规则设置有问题而没有回滚/溯源/复现的机制，将是很大的问题！！！
所以本质上就是要在规则引擎应用之上打造完善的版本控制，能够对规则历史进行溯源。
之前的文章风控系统建设，指标策略规则流程设计，LiteFlow隐式子流程，构造EL和Chain，提到了最终存储在es中大概有哪些数据。以下仅供参考，有部分还没做。
这里再次梳理一下：
1、基础数据，保留所有事件字段。
2、事件处理流程，也就是输入的数据经历了哪些流程和组件处理！
3、策略集结果，包括策略集、策略、规则的所有决策结果。还要加上特殊配置的策略执行流程。
4、指标数据，本次事件计算的所有指标数据。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
既然是商业软件，涉及到商业，那目的就是赚钱。
就拿IDEA举例，IDEA有多个版本，社区版功能少一些，本身使用上没有什么限制，而且省去了版权纠纷等问题；但是如果想要享受JetBrains的其他服务，那就必须要考虑商业化版本了，缺点可能就是贵一点。
像IDEA、Navicat
Premium这样的都是提供了客户端的软件服务，好像更加贴合我们对于软件的认识，然而我们日常生活中如iCloud、Windows、aliyun、google，包括视频会员、VIP本质上都一样，而且这些都可以与其用户体系打通，形成会员积分系统。
可以步入正题了，本篇文章讨论的不是用户会员体系，而是简单的许可证License。
许可证存在就是为了限制软件功能，不同的套餐对应不同的功能嘛！
如下，语雀套餐。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
https://juejin.cn/post/7005869798483558431
https://gitee.com/freshday/radar/wikis/home
在需要灵活配置规则的业务系统中，如上图这样的条件配置非常常见。
不管是在第一个参考链接（https://juejin.cn/post/7005869798483558431）里或是从自己的分析中都可以知道条件配置就是对同一逻辑单元的与或非编排。对于LiteFlow相同组件的编排有组件标签和组件参数两种解决方法。
通过组件标签实现，就是在编排LiteFlow时加上组件tag。
那么就将条件存储在数据库中，在组件运行时通过tag再到数据库中去取。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
前面有很多文章已经说了，我要利用LiteFlow做风控系统。至于进度嘛，只能尽力而为，毕竟我的惰性也很强。
下面是目前Git的提交记录，代码托管在Github和Gitee，但是是私有仓库，因为还不是开放的时候，还有很多要做的。
其中能梳理的仅是主流程的TODO都有下面这么多，更何况还有管理应用，es存储和检索设计开发还都没开始，更有前端规则/策略配置也还没做，还有在涉及画布的排版、数据的反显都还没有明确的解决方案。所以连个半成品都不算，不是开放的时候。
另外，也不知道我会不会中途放弃😝
