Protocol Buffers

1. 下载依赖 yum install -y boost-devel qt-devel protobuf-devel qrencode-devel libevent-devel libtool openssl-devel 2.下载 bitcoin core / omni core(usdt 节点) https://github.com/bitcoin/bitcoin.git https://github .com/OmniLayer/omnicore .git bitcoin 解压为 bitcoin-master usdt 解压为 omnicore-master 3. 安装libdb wget 'http://download.oracle.com/berkeley-db/db-5.1.29.NC.tar.gz' tar -xzf db-5.1.29.NC.tar.gz cd db-5.1.29.NC/build_unix/ ../dist/configure --enable-cxx --disable-shared --with-pic --prefix=/opt/bitcoin-master/db4/ (/opt/bitcoin-master 为2中解压的目录，usdt也要执行一次) make install 4. 打开到bitcoin (/opt/bitcoin

[TOC]##引言 对于分布式系统而言,不同的服务分布在不同的节点上,一个服务要完成自己的功能经常需要调用其他服务的接口,比如典型的微服务架构。通常这种服务调用方式有两种,一种是发送HTTP请求的方式,另一种则是RPC的方式,RPC是Remote Procedure Call(远程过程调用)的简称,可以让我们像调用本地接口一样使用远程服务。相比HTTP调用,RPC的方式至少在以下几个方面有优势 传输效率 RPC可以自定义TCP报文,基于TCP协议进行通信,比如dubbo;同时也支持使用HTTP2协议进行通信,比如gRPC。这相比传统的HTTP1.1协议报文体积会更小,传输效率会更高。 性能消耗 RPC框架通常自带高效的序列化机制,序列化和反序列化耗时更低,序列化后的字节数通常也更小。 负责均衡 RPC框架通常自带负载均衡策略,而HTTP请求要做负载均衡需要外部应用如Nginx的支持。 服务治理 下游服务新增,重启,下线时能自动通知上游使用者,而HTTP的方式需要事先通知并修改相关配置。 正因为基于RPC方式的服务调用有着性能消耗低,传输效率高,更容易做负载均衡和服务治理的优点,所以分布式系统内部大多采用这种方式进行分布式服务调用。可供选择的RPC框架很多,比如Hession,Dubbo,Thrift这些很早就开源,平时项目中使用也很多。不过最近有一个叫gRPC的RPC框架很火

云原生计算基金会（CNCF）正式发布GA版本的gRPC-Web，这是一个JavaScript客户端库，使Web应用程序能够直接与后端gRPC服务通信，不需要HTTP服务器充当中介。这意味着你现在可以通过.proto文件来定义客户端和服务器端数据类型和服务接口，轻松构建真正的端到端gRPC应用程序架构。gRPC-Web为Web开发提供了REST之外的另一个选择。 \\ 基础 \\ gRPC-Web让你能够使用.proto来定义客户端Web应用程序和后端gRPC服务器之间的服务“契约”，并自动生成客户端JavaScript（你可以选择Closure编译器或使用更为广泛的CommonJS）。你可以不用再为这些事情操心：创建自定义JSON序列化和反序列化逻辑、处理HTTP状态代码（可能因​​REST API而异）、Content-Type协商等。 \\ 从更广泛的架构角度来看，gRPC-Web让端到端的gRPC成为可能。如下图所示： \\ \\ 在左侧，一个客户端应用程序通过Protocol Buffers与一个gRPC后端服务器通信，然后这个服务器也通过Protocol Buffers与其他的gRPC后端服务器通信。在右侧，Web应用程序通过HTTP与后端REST API服务器通信，然后这个服务器又通过Protocol Buffers与其他后端服务通信。 \\ 需要明确指出的是

微服务设计的原则是单一职责、轻量级通信、服务粒度适当，而说到服务通信，我们熟知的有MQ通信，还有REST、Dubbo和Thrift等，这次我来说说gRPC， 谷歌开发的一种数据交换格式，说不定哪天就需要上了呢，多学习总是件好事。 准备： Idea2019.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Proto3.0/gRPC1.29.0 难度： 新手-- 战士 --老兵--大师 目标： 实现四种模式下的gRPC通信 说明： 为了遇见各种问题，同时保持时效性，我尽量使用最新的软件版本。 源码地址，其中的day28：https://github.com/xiexiaobiao/dubbo-project 1 介绍 先引用一小段官方介绍： Protocol Buffers - Google's data interchange format. Protocol Buffers (a.k.a., protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. Protocol Buffers，即protobuf，类比如JSON，XML等数据格式，实现了对结构化数据序列化时跨语言，跨平台，可扩展的机制

随着人口红利的慢慢削减，互联网产品的厮杀愈加激烈，大家开始看好下沉市场的潜力，拼多多，趣头条等厂商通过拉新奖励，购物优惠等政策率先抢占用户，壮大起来。其他各厂商也紧随其后，纷纷推出自己产品的极速版，如今日头条极速版，腾讯新闻极速版等，也通过拉新奖励，阅读奖励等政策来吸引用户。 对于这类APP，实时风控是必不可少的，一个比较常见的实时风控场景就是防刷接口作弊。刷接口是黑产的一种作弊手段，APP上的各种操作，一般都会对应后台的某个接口，用户操作APP数据就会通过接口上报到后台，但如果黑产通过破解获取到了APP的新增用户接口，那他们就能跳过登陆APP步骤直接调后台接口构造虚假数据牟利了。对于这类业务，我们可以通过Flink + Redis来实现实时防刷接口的功能。数据流图如下所示: 刷接口作弊一般是越过登陆APP操作，直接调Server端的接口发数据，这些用户在APP的上报日志里面就不存在，那我们可以通过Flink将APP实时上报上来的新增用户写入Redis中，然后Server端将接口上报上来的用户与Redis里的用户进行比对，如果不在Redis里面则判为刷接口用户。 对于这个需求，得要求实时计算引擎能达到毫秒级延迟，否则会造成用户的误判和影响用户体验。为此我们选择了Flink作为实时计算引擎。 主要代码逻辑如下： //配置flink运行环境 val env =

  众所周知，这几年微服务、云原生提得很火热。2017年，当时公司的领导刘巍，敏锐得提出公司转型微服务。那时，提到微服务大家一头雾水，经过两年的实践，逐渐有了一些心得。但有个问题始终萦绕在微服务开发者的头上，分布式事务到底如何解决，有没有比较完美的方案？二阶段提交、柔性事务、最终一致性？   2019 年，我注意到阿里巴巴的同学在社区调研分布式事务需求，立即加入了社区群。在 seata 0.2 版本的时候，当时还不叫 seata，叫 fescar，我看到 seata 代码仓库里只有 dubbo 结合 seata 的 sample，随即在博客园写了一篇 spring boot 如何结合 seata 的博文 Spring Boot微服务如何集成seata解决分布式事务问题？ ，这篇文章后来被收录到 seata wiki 里面，收获到了 18000+ 的阅读量，是我阅读量最高的一篇博客。   后来，由于工作比较忙，屡次想参与 seata 贡献，发现了几个 bug，本来想修改来着，结果看社区里边已经有人在做了😂。   由于接触微服务，自然而然接触到 k8s 技术，接触到云原生，接触到 golang。个人对 golang 比较感兴趣，比较看好它的未来。看到社区里面也有关于 seata go client 的呼声，遂萌生了打造 golang 版 seata 的想法。   有人问：喂，同学

转自https://blog.csdn.net/baiye_xing/article/details/76735113 1.BIO、NIO和AIO的区别？ BIO：一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。线程开销大。 伪异步IO：将请求连接放入线程池，一对多，但线程还是很宝贵的资源。 NIO：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。 AIO：一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理， BIO是面向流的，NIO是面向缓冲区的；BIO的各种流是阻塞的。而NIO是非阻塞的；BIO的Stream是单向的，而NIO的channel是双向的。 NIO的特点：事件驱动模型、单线程处理多任务、非阻塞I/O，I/O读写不再阻塞，而是返回0、基于block的传输比基于流的传输更高效、更高级的IO函数zero-copy、IO多路复用大大提高了Java网络应用的可伸缩性和实用性。基于Reactor线程模型。 在Reactor模式中，事件分发器等待某个事件或者可应用或个操作的状态发生，事件分发器就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。如在Reactor中实现读：注册读就绪事件和相应的事件处理器

01| 简介 02| 安装 2.1 Windows 下安装 03| 简单使用 3.1 编译 3.2 Python 示例 3.3 C# 示例 01| 简介 Protobuf（Protocol Buffers），是 Google 开发的一种跨语言、跨平台的可扩展机制，用于序列化结构化数据。 与 XML 和 JSON 格式相比，protobuf 更小、更快、更便捷。protobuf 目前支持 C++、Java、Python、Objective-C，如果使用 proto3，还支持 C#、Ruby、Go、PHP、JavaScript 等语言。 官网地址： https://developers.google.cn/protocol-buffers/ GitHub 地址： https://github.com/protocolbuffers/protobuf 优点： 性能好 跨语言 缺点： 二进制格式可读性差：为了提高性能，protobuf 采用了二进制格式进行编码，这直接导致了可读性差。 缺乏自描述：XML 是自描述的，而 protobuf 不是，不配合定义的结构体是看不出来什么作用的。 02| 安装 2.1 Windows 下安装 下载地址： https://github.com/protocolbuffers/protobuf/releases 下载 protoc-3.9.1-win64

Protocol Buffer 是 Google 搞的 RPC 服务的中间层数据协议。其实 RPC 服务之间可以用各种数据格式，例如 JSON、XML 等。但考虑编解码效率和传输效率的话，Protobuf 性能更好。 此外，Protobuf 还包含了一个编译器，可以把 proto 文件编译成各种语言对应的代码。 安装 下载源码 git clone https://github.com/protocolbuffers/protobuf.git 安装依赖库 Protocol Buffer 是 C++ 编写的，主要是安装 g++ 编译器： sudo apt-get install autoconf automake libtool curl make g++ unzip 编译安装并更新共享库 cd protobuf/ ./autogen.sh ./configure make sudo make install sudo ldconfig 测试 protoc -h 安装 Golang 的 proto API 每种语言在使用 Protobuf 时，通过调用现成的库来实现转换。Go 语言的 API 库安装方式： go get -v -u github.com/golang/protobuf/proto 安装 protoc-get-go 插件 Protobuf 官方不支持自动生成 Go 代码

一、简介 webrtc提供了一个实时数据捕获RtcEventLog接口。通过该接口可以实时捕获进出webrtc的RTP报文头数据、音视频配置参数、webrtc的探测数据等。详细可参考RtcEventLogImpl类定义。 void LogVideoReceiveStreamConfig(const rtclog::StreamConfig& config) override; void LogVideoSendStreamConfig(const rtclog::StreamConfig& config) override; void LogAudioReceiveStreamConfig(const rtclog::StreamConfig& config) override; void LogAudioSendStreamConfig(const rtclog::StreamConfig& config) override; void LogRtpHeader(PacketDirection direction, const uint8_t* header, size_t packet_length) override; void LogRtpHeader(PacketDirection direction, const uint8_t* header, size_t