自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(8)
  • 收藏
  • 关注

原创 vertx构建高性能策略网关的解决方案

通过各种方式组建集群(框架本来支持多种方式,也可以自定义集群组成方式,例如ETCD、k8s的apiserver等,扩展集群类,重写心跳检测等),并将集群管理器和节点元数据等保存全局上下文。剩下的,我们通过反射机制在服务启动时,自动注册controller层的路由,vertical部署时,自动发布集群间调用的服务,然后通过上下文,手动写一下,管理好我们的bean就行了。通过以上方案,集群间强一致性,且集群故障时在客户端节点和其他节点上打印的日志都会十分清晰明确,方便故障排查。4. 全局异常处理。

2024-05-17 16:15:07 331

原创 看 宁玉&晓梦 是如何在日本特务监听中,安全进行对称秘钥交换的 --一文读懂SSL/TLS安全通信整个过程

但是仔细一斟酌,宁玉和晓梦发现,这样的方案还是有漏洞,宁玉给晓梦发送公钥时,假如某大佐把公钥截获并据为己有,同时把自己的公钥给晓梦,晓梦收到公钥,对通讯的密码加密,此时她并不知道她用的公钥已不是宁玉给她的那一把,而是被某大佐替换掉的,某大佐截获到通讯内容后,用自己的私钥对通讯内容解密,并篡改其中的内容后,用上一步截获的宁玉的公钥进行加密,并转发给宁玉,宁玉并不知道收到的内容是某大佐篡改过的,失败,o(╥﹏╥)o。但是作为数学天才的宁玉和晓梦,怎么会做这么冒险的事情呢,因此她俩合计,如果逃过某大佐的耳目。

2024-01-14 23:07:27 438

原创 K8s部署zookeeper的一系列问题

最后分析zookeeper日志和客户端连接机制等发现,恢复的这些节点,都是temp节点,当zk发现之前连接的session无法恢复时,就会清除这些注册信息,那么问题迎刃而解了,k8s固定ip的机制吧,那就新建个Reservation固定IP吧,session可以恢复了,注册信息不被剔除了,最后经过验证,要解决我们的问题(当然基于我们用的版本),使用statfulset部署+持久化+固定IP三者缺一不可。②zookeeper发生异常后通过k8s恢复机制自动拉起,但是三个zk节点就不属于一个集群了。

2024-01-14 23:05:17 437 1

原创 看 宁玉&晓梦 是如何在日本特务监听中,安全进行对称秘钥交换的 --一文读懂SSL/TLS安全通信整个过程

但是仔细一斟酌,宁玉和晓梦发现,这样的方案还是有漏洞,宁玉给晓梦发送公钥时,假如某大佐把公钥截获并据为己有,同时把自己的公钥给晓梦,晓梦收到公钥,对通讯的密码加密,此时她并不知道她用的公钥已不是宁玉给她的那一把,而是被某大佐替换掉的,某大佐截获到通讯内容后,用自己的私钥对通讯内容解密,并篡改其中的内容后,用上一步截获的宁玉的公钥进行加密,并转发给宁玉,宁玉并不知道收到的内容是某大佐篡改过的,失败,o(╥﹏╥)o。但是作为数学天才的宁玉和晓梦,怎么会做这么冒险的事情呢,因此她俩合计,如果逃过某大佐的耳目。

2024-01-14 23:01:33 315 1

原创 一个关于开闭原则和依赖倒置原则的代码重构案例

此时如果扩展一项功能,比如可以根据用户录入的模板生成代码,那就需要修改CodeGeneratorUtil类了,如果在项目中这样写也是可以的,但是如果要做成框架,提供给其他用户调用,那就不合适了。2. 以下为数据库模板和FreeMark模板的实现类,如果要扩展用户录入的自定义模板,可以新增一个ICodeTemplate实现类,并实现接口中的方法。3. 新增CodeGenerator类,组合ICodeTemplate接口,并通过调用其方法,实现代码的动态生成。开闭原则:开闭原则就是说对扩展开放,对修改关闭。

2024-01-14 23:00:36 414

原创 将时间复杂度降到O(1)计算客户N年累计余额

但有一种特殊情况,实际开发的时候,我们有本年累计,本月累计等N个指标,因为要一次检索计算这N个指标,所以捞库的where条件应以最大时间段的过滤,但是在计算本月累计时,可能存在如图灰色的线段条情况,与当期并无交集,比如初始化时间为2021年2月27日,表中存在2021年1月1日-2021年1月10日的数据,计算本月累计时显然应该算成0。求助无果,不想就这样被打败,其实主要是害怕后续业务规则再有改动,或者某个细节没注意算错,再去重新累计,太重量级,怕给以后的自己添麻烦,费点时间自己琢磨琢磨吧。

2024-01-14 22:59:32 882

原创 Sql编程--有点烧脑的,看看你能做到第几题

但有一种特殊情况,实际开发的时候,我们有本年累计,本月累计等N个指标,因为要一次检索计算这N个指标,所以捞库的where条件应以最大时间段的过滤,但是在计算本月累计时,可能存在如图灰色的线段条情况,与当期并无交集,比如初始化时间为2021年2月27日,表中存在2021年1月1日-2021年1月10日的数据,计算本月累计时显然应该算成0。对于每行数据,有效累计余额为,本行开始日期到本行结束日期,与当期日期即本年求交集,乘本行余额,因此对于每行数据,我们有:。

2024-01-14 22:56:19 877

原创 这种场景优化后性能何止提升百倍千倍

①发现问题 偶然一次看代码的过程中,发现该网关用的线程组,而交易时阻塞式的,理论上是存在问题的,即有限的线程数承接了阻塞式服务,即使网关本身无耗时交易,后端服务的交易时间是不可控的,这样后端交易慢的情况下,线程必然被阻塞,就好比公司雇了100个人去卖东西,东西卖出去了就在那等着收钱,假如客户交钱有点慢,新来买东西的客户就没法为他们提供服务了,需要排队等。对于系统来说,这是致命的。一点败笔之处就是多个线程共享内存来共享变量了,最好的方式实际是eventbus事件总线传递的,我也懒吧,haha。

2024-01-14 22:35:16 444

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除