hessian

瘟疫期间在家宅出的 RPC 框架

半腔热情 提交于 2020-02-27 06:31:27
TIANAI-RPC https://gitee.com/tianai/tianai-rpc TIANAI-RPC 码云地址 https://gitee.com/tianai/tianai-rpc-springboot-starter TIANAI-RPC 的springboot快速启动包 如果有兴趣想一起参与的小伙伴欢迎加QQ群: 1021884609 笔者为什么写这个RPC框架呢?? 这一切都要从一只 蝙蝠 说起... 苦思冥想一晚上不得解, 为什么要吃蝙蝠? 难道是想上天??? 瘟疫满天飞 工作不得找 花呗天天催 血从心中流 笔者在兼职都找不到,工作又找不到的双重鼓励下 笔者头悬梁锥刺股耗尽心血写出这个看似很牛x的RPC框架 ​ 该RPC框架目前实现有 基于zookeeper的服务注册 增加基于nacos的服务注册 基于Netty实现的远程通讯 基于hessian2实现的序列化、反序列化 实现了基于轮询策略的负载均衡 使用Netty自带的心跳机制实现心跳机制 实现网络抖动后造成的链接断开后重连 该RPC框架的稳定性通过 本人 基本测试,亦可用于中小型rpc通讯,比 dubbo 更加轻量 TIANAI-RPC基本使用 server端: public class RpcServerImplTest2 { public static void main(String\[\]

dubbo 反序列化空指针排查

独自空忆成欢 提交于 2020-02-27 06:24:05
dubbo 反序列化空指针排查 背景 一个线上问题,dubbo provider 接收到的dto对象时,报空指针错误。但是将同样的dto第二次调用,就没问题。异常如下 java.lang.NullPointerException: null at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at com.alibaba.com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeserializer.java:305) at com.alibaba.com.caucho.hessian.io

【模块十四】分布式篇--Dubbo框架篇☞参考答案

╄→尐↘猪︶ㄣ 提交于 2020-02-27 03:05:36
一、Dubbo 简介 1、是什么? Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架 它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。 2、为什么使用? A、产生原因 随着服务化的进一步发展,服务越来越多,服务之间的调用和依赖关系也越来越复杂,因此诞生了面向服务的架构体系(SOA),Dubbo这样的 布式系统的服务治理框架也随之产生。 B、作用 而dubbo在整个分布式系统的架构中,按照分层的架构来架构,使得各个层级之间最大限度的松耦合。 1.透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。 2.软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。 3. 服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。 3、注册 与 发现原理 结构图一定要能画出来,并解释清楚每个角色,下面为Dubbo官网原理图 节点角色说明: Container:服务运行器 Provider:暴露服务的服务提供方 Consumer:调用远程服务的服务消费方 Register:服务注册与发现的注册中心 Monitor:统计服务的调用次数和调用时间的监控中心 调用流程说明: 1.服务容器负责启动,加载

dubbo协议及序列化

帅比萌擦擦* 提交于 2020-02-27 00:31:05
Dubbo是 Alibaba 开源的分布式服务框架远程调用框架,在网络间传输数据,就需要通信协议和序列化。 一、通信协议 通信协议:Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议,但是Dubbo官网是推荐我们使用Dubbo协议的,默认也是用的dubbo协议。 dubbo协议 缺省协议,使用基于mina1.1.7+hessian3.2.1的tbremoting交互。 连接个数:单连接 连接方式:长连接 传输协议:TCP 传输方式:NIO异步传输 序列化:Hessian二进制序列化 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用dubbo协议传输大文件或超大字符串。 适用场景:常规远程服务方法调用 总结: 1、dubbo默认采用dubbo协议,dubbo协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况 2、他不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。 配置如下: <dubbo:protocol name="dubbo" port="20880" /> <dubbo:protocol name=“dubbo” port=“9090” server=“netty”

Iterative CBCT reconstruction using Hessian penalty

半城伤御伤魂 提交于 2020-01-29 15:09:13
TV正则作为惩罚项具有明显的阶梯效应,会使图像不自然,这篇文章为了解决这个问题,提出了利用图像Hessian矩阵的Frobenius范数的二阶导数作为惩罚项进行CBCT重建,可以有效抑制TV惩罚项的阶梯效应。 TV惩罚项优先最小化一阶导数,因此往往具有分段函数结果。在这次研究当中,我们提出了使用hessian惩罚来进行CBCT重建。这就会涉及到图像的hessian矩阵的F范数来抑制TV惩罚中的阶梯效应。其中,Hessian惩罚是二阶导数惩罚。这背后的动机是二阶导数对于相邻像素之间的绝对差有较弱的惩罚,并且允许分段地平滑重建结果。 对于之前的重建方法,大多数的惩罚项都是二次式的,因此相关目标函数的优化可以直接进行,例如 高斯-赛德尔 和 共轭梯度法 。 但是不幸的是hessian惩罚不是二次式的,这就会让目标函数的最小化具有挑战性。作者发展了一种有效的算法来最小化目标函数—MM算法。 图像去噪的能量泛函: 第一项式加权最小二乘元作为(WLS)或数据保真项。对角线矩阵Σ的元素在WLS损失函数中起着加权的角色,决定着每项的贡献。第二项是先验约束或一个惩罚项。图像重建任务是通过最小化具有正约束的目标函数来找到一个衰减系数图像μ hessian惩罚 由于上式中的先验约束强制了平滑约束,图像的TV最小化在CBCT重建中在噪声抑制和边缘保持中显示了良好的作用。让μ是连续可微的三维图像

XXL-JOB使用问题总结

≯℡__Kan透↙ 提交于 2020-01-11 06:25:39
问题一: XXL-JOB的服务器端和用户端版本必须保持一致,不然会报错 问题二: 由于 xxl-job使用的一些依赖包与原有项目中的依赖包存在版本冲突 , 造成 java.lang.NoClassDefFoundError 错误 本人实际遇到问题: 1、报错信息如下,造成该问题原因,由于hessian包版本如项目中其他包存在冲突造成,解决方案,移除xxl-job自带的hessian 添加更低版本的包。 Exception in thread "xxl-job, executor ExecutorRegistryThread" java.lang.NoClassDefFoundError: com/caucho/hessian/io/Hessian2Output at com.xxl.rpc.serialize.impl.HessianSerializer.serialize (HessianSerializer.java:21) at com.xxl.rpc.remoting.net.impl.netty_http.client.NettyHttpConnectClient.send (NettyHttpConnectClient.java:101) at com.xxl.rpc.remoting.net.common.ConnectClient.asyncSend

Dubbo协议

喜欢而已 提交于 2020-01-10 13:45:50
参考dubbo官方文档http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html dubbo共支持如下几种通信协议: dubbo:// (缺省) rmi:// hessian:// http:// webservice:// thrift:// memcached:// redis:// 部分协议的特点和使用场景如下: 1、dubbo协议 Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。 缺省协议,使用基于mina1.1.7+hessian3.2.1的tbremoting交互。 连接个数:单连接 连接方式:长连接 传输协议:TCP 传输方式:NIO异步传输 序列化:Hessian二进制序列化 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用dubbo协议传输大文件或超大字符串。 适用场景:常规远程服务方法调用 常见问题 为什么要消费者比提供者个数多? 因 dubbo 协议采用单一长连接,假设网络为千兆网卡 [3] ,根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样,供参考),理论上 1 个服务提供者需要 20

Dubbo 面试18问

北战南征 提交于 2020-01-10 11:07:17
dubbo是一个分布式框架,远程服务调用的分布式框架,其核心部分包含: 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。 dubbo能做什么 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。 1、默认使用的是什么通信框架,还有别的选择吗? 答:默认也推荐使用 netty 框架,还有 mina。 2、服务调用是阻塞的吗? 答:默认是阻塞的,可以异步调用,没有返回值的可以这么做。 3、一般使用什么注册中心?还有别的选择吗? 答:推荐使用 zookeeper 注册中心,还有 Multicast注册中心, Redis注册中心, Simple注册中心.ZooKeeper的节点是通过像树一样的结构来进行维护的,并且每一个节点通过路径来标示以及访问

Spring AOP ignores some methods of Hessian Service

江枫思渺然 提交于 2019-12-24 03:29:23
问题 I have an Aspect with the following pointcut definition @Pointcut("execution(public de.company.project..* *(..))") and a spring configuration containing the following <aop:aspectj-autoproxy /> <bean id="myaspect" class="de.company.project.impl.MyAspect" /> <bean id="someService" class="de.company.project.impl.SomeService" /> <bean name="/SomeService" class="org.springframework.remoting.caucho.HessianServiceExporter"> <property name="service" ref="someService" /> <property name=

Hessian矩阵与多元函数极值

旧时模样 提交于 2019-12-22 11:32:09
Hessian矩阵与多元函数极值 海塞矩阵(Hessian Matrix),又译作海森矩阵,是一个多元函数的二阶偏导数构成的方阵。虽然它是一个具有悠久历史的数学成果。可是在机器学习和图像处理(比如SIFT和SURF特征检測)中,我们也经常遇到它。所以本文就来向读者道一道Hessian Matrix的来龙去脉。本文的主要内容包括: 多元函数极值问题 泰勒展开式与Hessian矩阵 多元函数极值问题 回忆一下我们是怎样处理一元函数求极值问题的。 比如。 f ( x ) = x 2 ,我们会先求一阶导数,即 f ′ ( x ) = 2 x ,依据费马定理极值点处的一阶导数一定等于 0 。但这仅是一个必要条件。而非充分条件。对于 f ( x ) = x 2 来说,函数的确在一阶导数为零的点取得了极值,可是对于 f ( x ) = x 3 来说,显然只检查一阶导数是不足以下定论的。 这时我们须要再求一次导,假设二阶导数 f ″ < 0 ,那么说明函数在该点取得局部极大值;假设二阶导数 f ″ > 0 ,则说明函数在该点取得局部极小值;假设 f ″ = 0 。则结果仍然是不确定的,我们就不得不再通过其它方式来确定函数的极值性。 假设要在多元函数中求极值点,方法与此相似。 作为一个演示样例。最好还是用一个三元函数 f = f ( x , y , z ) 来作为演示样例