qq_32784081的博客

因为之前redis的报文解析脱敏已经用netty做过了，所以从当初决定选用了godlp开始就决定要要基于mongodb的报文解析来脱敏mongodb的数据，由于当初周末时间不够就选用了redis的报文解析来做阶段性成果，但是性格有点强迫症，既然定了这个目标不完成总觉得心里一直压着一点东西，所以就还是趁周末把这件事完成了，至此已经完成的数据库有关系型数据库（mysql,postgrepsql,maraidb）,非关系型数据库（redis，mongodb）常用的开源数据库基本就这些了吧。

godlp扩展，基于godlp的实际应用，通过端口代理拦截数据库返回内容用godlp提供的敏感识别规则进行敏感数据脱敏，一套完整的非关系型数据库动态脱敏系统--基于redis实现

如何基于java代理对大数据缓存组件返回的数据进行脱敏和阻断背景架构拓扑图实现方式对比UDF方案优点：缺点：改写返回结果方案优点：缺点：说明实现默认处理方式redis报文解析器代码解析测试方案前提条件测试脚本及命令最终效果温馨提示：背景上周刚把基于关系型数据库的拦截及脱敏的代码做了一些完善与修复，开源关系型数据库已经都做了，其他的数据库也不方便再公开了，但是问题来了，其原理事拦截客户端的请求修改请求发送给服务端的，如果说服务端事非关系型的大数组组件数据库不支持这样的复杂请求又该怎么办呢，那就只能拦截返回

如何用一台服务器的代码端口转发数据库的所有流量并对相关操作进行记录，修改或阻背景一年结束了，又是新的一年开始了，针对前段时间研究的内容做一个简单的总结，上次写文章还是在上次，写的内容是基于netty做的一个tcp端口动态代理的的工程，当时做这个工具的目的是为了解决两台服务器之间不能直接通信所以在一台两个服务都能访问的代理服务器上去转发流量的问题，但是这个工程就只做了流量的的转发，并没有对流量进行解析，那么这篇文章就基于上个工程做一个简单的扩展，对转发的流量进行解析，几里路日志，拦截或篡改。

基于netty模型实现一个tcp端口的代理背景上一篇文章说到了怎么使用bio和nio模型来实现基于tcp的端口代理，但是基于bio的模型缺点很明显，当并发数量上来之后会创建大量线程，这样的性能肯定是不可取的，而基于nio的模型虽然处理了线程数据的问题，但是仍然存在缺点，因为服务端的业务逻辑处理，数据转发这部分是单线程的，把比如我像要使用的一个业务用语代理sftp端口去上传下载文件，如果说有一个连接在处理一个大文件耗时很长那么服务端的转发数据线程会一直被占用，那么其他的用户在请求代理地址的时候就无法使用了

基于IO模型实现一个tcp端口的代理背景最近研究了io通信模型，但是没有经历过实践的学习其实是没有意义的，所以希望能通过实现一些实用的东西来发现学习中的不足。关于日常的端口代理我们常见的就是nginx可以代理http端口，当然也可以代理tcp端口，不过代理tcp端口是需要安装插件的，对于一些管理比较严格的公司软件是不允许自己安装的，对于插件的安装也有要求，虽然软件拥有功能但是并不一定允许使用，如果一味的把希望寄托在软件上不是一个明智的选择，所以选择了使用io通信实现一个tcp端口的代理工具。原理说到