行业动态

智能程序不可用
作者:利发88 发布时间:2020-02-25 23:06

  以太坊的核心元素是以太坊虚拟机Ethereum Virtual MachineEVM它是智能合约的执行环境。EVM分散储存在以太坊网络的每个节点上智能合约代码被对外隔离并分布在每个节点上执行因此以太坊EVM又被称为世界电脑。合同代码不是用图灵完备的高级程序语言编写的而是由简单的、基于堆栈的低级程序语言编写的看起来就像JVM的字节码Java虚拟机。每个以太坊节点都运行EVM这意味着对于以太坊网络的参与者每个节点都参与验证新块是否有效以及计算是否已正确都是运行EVM代码的独立实例。由于每个节点都参与计算虽然不一定是最高效的模型但它具有很高的加密安全性。 从技术上讲EVM以状态转换作为函数的运作模式其工作原理是将一串参数输入EVM以获取整个以太坊网络的新区块状态和gas数量具体过程为输入block_stategasmemorytransactionmessagecodestackpc→EVM→输出block_stategas。其中block_state是以太坊网络的全局状态包括所有账户、账户余额和长期存储gas是运行这些计算所需的费用由计算的类型和工作量决定memory是执行内存transaction代表交易message是有关交易的元数据code就是代码本身stack和pc是与执行相关的堆栈和程序计数器。这一串参数被输入到EVM以生成整个以太坊网络的新block_state和账户拥有的新gas数量。 以太坊EVM的设计目标有5个简单、高效、确定性、专用化和安全性。EVM设计简单可以轻松证明智能合约的安全性这也有助于保护平台本身。EVM组件尽可能紧凑以提高空间效率。EVM具有确定性即相同的输入状态应始终产生相同的输出状态。确定性的虚拟机必然会限制应用范围例如以太坊的HTTP请求不可用。EVM具有专用的内置函数例如可以轻松处理20字节地址加密的加密函数、用于自定义加密的模块化指数算法、读取区块数据、读取交易数据的函数以及与block_state交互的函数。以太坊EVM的安全性在于每次计算都要预先消耗gas这增加了DoS攻击的成本使得攻击者无法发动大规模的无效合约。EVM的主要编程语言是Solidity智能合约用Solidity写好后通过Solidity Compilersolc编译并生成EVM代码。合约语言的复杂性通过Solidity Compiler进行管理但在架构层面Solidity仍然是一种简单的基于堆栈的语言。 智能合约是在以太坊EVM上自动执行的合约代码一般包括合约所有人、合约对象、合约条款、合约算法、合约触发条件等内容。对于可信电子证照应用数据共享规则被转换为智能合约并部署在区块链上之后常规共享条款和违约处理条款就可以自动履行且执行过程由区块链完整记录其执行状态可被随时查看和审计从而提供一个公平、公正、公开的合约执行环境。此外通过智能合约还可对参与方身份进行权限检查针对交易者身份进行访问控制。 用智能合约完成可信电子证照应用的注册、发证、查验等过程具体包括5个主要功能模块和5个API。5个主要功能模块为公民用户App、发证机构前端、区块链平台、政府业务库和后台身份管理数据库5个API包括注册区块链用户、发送制证信息、查验电子证照信息、查询用户公钥和查询电子证明信息具体分析如下所示。 1. 注册区块链用户 用于新用户注册区块链信息管理账户。对于业务系统注册账号来说分为3个不同的角色普通用户、制证机关用户、查验机构用户。 输入账户名称用于登录系统的ID。 输出账户地址注册用户在区块链上的地址用于用户之间传输信息和账户公私钥普通用户的公私钥用于用户证件信息的加解密制证机关用户的公私钥用于对发证机构的数字签名进行验证查验机构用户的公私钥用于对查验信息的加解密。 2. 发送制证信息 用于制证机构用户存储新增证件信息以及发送给办证用户。以制证机构用户在区块链上给办证用户发送一笔交易为载体把新增的证件信息保存在区块链上并发送给办证用户。 输入申请制证用户的区块链地址发证机构制证后给该地址用户发送制证信息、发证机构组织机构代码发证机构的唯一标示、申请制证用户的证件信息需要用户公钥加密。 输出该笔交易的Hash值交易信息地址唯一标识、记录证件信息的区块编号交易信息地址唯一标识。

  您好阿里云的短信服务是一项基础通信服务提供的是通信接口没有您想要的那种电脑客户端。 不过实际是上使用并不复杂 官方提供了包括node.js的demo 如果您本身非程序人员可以委托其他人编写一个简单的客户端实现短信发送功能。 但对于个人用户在使用上尤其在短信签名上有很高要求可详见 建议您在使用前详读短信服务的文档确定是否可用。 - - - - - - 作者Aspirant Zhang 职业中小型网站制作与运维管理 注意非阿里云官方客服知道平台为技术爱好者根据个人经验为您提供处理指引请勿在本平台泄露网址、IP地址、账户密码及个人信息。非官方回复仅供参考。 善用智能解答助手输入问题关键字如“ECS退款”阿里云问题不求人 善用网站自检工具输入网址自动检测确诊网站表面问题仅3秒

  目前已经有多个国家将区块链技术运用于能源系统其中电动汽车快充和共享充电桩是区块链技术在能源方面应用最广、操作性较强的领域。美国清洁能源技术公司Oxygen Initiative联合德国能源公司Innogy SE加入“ShareCharge”区块链平台司机可以在该平台上处理与清洁能源汽车相关的操作包括允许司机共享他们的充电站、支付通行费和充电电动汽车。该平台依靠以太坊来运营特别是以太坊所支持的智能合约和分布式账本技术从而实现计费的透明化及信任化。具体就是在区块链上创建一个代币并在该代币上分配以欧元计价的移动价值。“ShareCharge”创建了一个分布式市场颠覆了传统的能源服务模式来自合作伙伴的第三方服务是共享的而无须询问权限或使用烦琐的应用程序编程接口。 另外2016年瑞士银行、德国电力公司莱茵集团RWE 与汽车技术公司采埃孚ZF合作为电动汽车创造区块链电子钱包。如图2-2所示电动汽车车主的电力收费、停车收费甚至高速公路收费在身份验证和支付过程都能自动完成不需要有第三方人工确认完成。RWE目前正在尝试在无人驾驶电动汽车领域应用区块链技术用户身份信息得到认证当车主不需用车时将其租出通过电子形式就车的使用达成协议再将协议编码成智能条约用车完成后自动向用车人收取费用用车人会向车主支付费用。无人驾驶电动汽车共享服务的车主和用户间的结算、交易信息将同时更新这将最大限度地降低交易成本而这一切操作都没有第三方参与。 在分布式智能电网领域Tennet公司与电池供应商Sonnen合作使用IBM的区块链软件运营欧洲第一个由区块链控制的电力稳定计划。可再生能源可能是清洁、环保的但因为受气候、天气的影响在需要的时候并不总是可用的。该项目的核心思想就是采取一种新方法来更好地整合分散的可再生能源并实现安全供应以鼓励公民积极参与能源转型。具体步骤是Sonnen为房主提供电池当他们不用电的时候可以在家里储存电力。在Sonnen Community上这些电池是联网的并连接到Tennet的传输系统这样电力分配器就可以在需要时利用附近的存储电力或者将多余的能量转移到电池中。这种方式让家庭设备真正成为电网基础设施的一部分而不仅仅是一个用电终端从而节省输电运营商用在网络管理上的昂贵费用。 此外还有欧洲能源联盟推出的Scanergy项目将NRGCoin作为可再生能源经济的润滑剂旨在实现小用户绿色能源的直接交易。如图2-3所示区块链一方面将产消两端直接对接另一方面将这种市场上的新型交易规范化。系统每15分钟监测一次网络的生产消费状态并向能源供应者提供NRGCoin作为奖励当购电方期望购买绿色清洁能源时需使用NRGCoin支付。由区块链智能合约锁定的NRGCoin不受外部政策和汇率波动的影响消除了绿色能源生产者对市场政策变更的担心为消费者提供更加优惠的绿色能源。 与Tennet和Scanery项目应用场景类似的知名项目还有2015年美国能源公司LO3 Energ与区块链公司Consensus合作的TransActive Grid。该项目将以太坊用于能源支付其核心思想是分布式光伏的电压等级比较低电力经不起远距离运输消耗只能用于本地消纳基于本地的能源微网通过区块链实现这样点对点的用户和发电者之间的电力交易。TransActive Grid项目就是采用点对点的方式将布鲁克林区的总统大道一侧5个家庭的剩余太阳能转为发电然后出售给对面5个家庭通过智能仪表进行连接和数据共享用创建代币表示一定电量通过仪表内的钱包进行交易。这是一个区块链网络连接交易不需要依赖第三方电力公司的参与每个家庭既是电力消费者同时也是电力生产者这种微电网点对点交易的模式见图2-4比传统自上而下的电力分配系统更有效率且节省开支。TransActive Grid项目经过PoC后LO3于2017年推出了升级版的Grid其加入智能代理设备帮助用户做出购买电力的决策并提供个性化的能源服务大规模运用区块链技术建立新的家庭能源供应商模式。

  MQTT协议 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)最早是IBM开发的一个即时通讯协议,MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台,它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性:1、使用发布/订阅消息模式,提供一对多的消息发布和应用程序之间的解耦;2、消息传输不需要知道负载内容;3、使用 TCP/IP 提供网络连接;4、有三种消息发布的服务质量:QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。5、小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量;6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小,最小的数据包只有2个bit,且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布/订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的,所以只有少量的内存空间和有限的计算能力,传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此,IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN(面向低功耗无线)的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。NON——不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。ACK——应答消息,接受到CON消息的响应。RST——复位消息,当接收者接受到的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式,最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子: 比如某个设备需要从服务器端查询当前温度信息。 请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C” ,响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。从应用方向来分析,主要区别有以下几点: 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol,超文本传输协议,这个协议的提出就是为了提供和接收HTML界面,通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程,Request和Response,两个都有各自的语言格式,我们看下是什么。请求报文格式:(注意这里有个换行) 响应报文格式:(注意这里有个换行) 方法method:       这个很重要,比如说GET和POST方法,这两个是很常用的,GET就是获取什么内容,而POST就是向服务器发送什么数据。当然还有其他的,比如HTTP 1.1中还有:DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法(HTTP Method历史:HTTP 0.9 只有GET方法;HTTP 1.0 有GET、POST、HEAD三个方法)。请求URL:       这里填写的URL是不包含IP地址或者域名的,是主机本地文件对应的目录地址,所以我们一般看到的就是“/”。版本version:       格式是HTTP/.这样的格式,比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本,现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字,代表的是请求过程中所发生的情况,比如说200代表的是成功,404代表的是找不到文件。原因短语reason-phrase:       是状态码的可读版本,状态码就是一个数字,如果你事先不知道这个数字什么意思,可以先查看一下原因短语。首部header:       注意这里的header我们不是叫做头,而是叫做首部。可能有零个首部也可能有多个首部,每个首部包含一个名字后面跟着一个冒号,然后是一个可选的空格,接着是一个值,然后换行。实体的主体部分entity-body:       实体的主体部分包含一个任意数据组成的数据块,并不是所有的报文都包含实体的主体部分,有时候只是一个空行加换行就结束了。 下面我们举个简单的例子: 请求报文:GET /index.html HTTP/1.1    Accept: text/*Host: 响应报文:HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议,基于REST(表述性状态传递)架构风格,支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式,最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多,太重,不够灵活。 XMPP协议 XMPP(可扩展通讯和表示协议)是一种基于可扩展标记语言(XML)的协议, 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础,而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器,然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML(标准通用标记语言的子集)流是什么样子的?客户端:123456?xmlversion=1.0?to=example_comxmlns=jabber:clientxmlns:stream=http_etherx_jabber_org/streamsversion=1.0服务器:1234567?xmlversion=1.0?from=example_comid=someidxmlns=jabber:clientxmlns:stream=http_etherx_jabber_org/streamsversion=1.0工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西, 中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流,关闭TCP/IP连接。  网络通信过程中数据冗余率非常高,网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说,大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备,省电、省流量是所有底层服务的一个关键技术指标,XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范,是一种轻量的、简单的、 基于可扩展标记语言(XML)的协议,它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP), 简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到 远程过程调用(RPC)等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结: 从当前物联网应用发展趋势来分析,MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商,比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早,所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展,后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者:HFK_Frank 来源:CSDN 原文:版权声明:本文为博主原创文章,转载请附上博文链接!

  转自阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问 谁选型是负责采购的同学、 DBA 还是业务研发 如果选型的是采购的同学他们更注重成本包括存储方式、网络需求等。 如果选型的是 DBA 同学他们关心的 ① 运维成本 首先是运维成本包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等 ② 稳定性 其次DBA会关注稳定性包括是否支持数据多副本、服务高可用、多写多活等 ③ 性能 第三是性能包括延迟、QPS 以及是否支持更高级的分级存储功能等 ④ 拓展性 第四是扩展性如果业务的需求不确定是否容易横向扩展和纵向扩容 ⑤ 安全 最后是安全需要符合审计要求不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外后台应用研发的同学同样会关注稳定性、性能、扩展性等问题同时也非常关注数据库接口是否便于开发是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型 MySQL互联网业务必备系统 TiDB爱奇艺的 TiDB 实践会有另外的具体介绍 RedisKV 数据库互联网公司标配 Couchbase这个在爱奇艺用得比较多但国内互联网公司用得比较少接下来的部分会详细说明 其他比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等 大数据分析相关系统比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么我们先对这些数据库按照接口SQL、NoSQL和面向的业务场景OLTP、OLAP这两位维度进行一个简单非严谨的分类。 下图中左上角是面向 OLTP、支持 SQL 的这样一类系统例如 MySQL一般支持事务不同的隔离级别 QPS 要求比较高延时比较低主要用于交易信息和关键数据的存储比如订单、VIP 信息等。 左下角是 NoSQL 数据库是一类针对特殊场景做优化的系统schema 一般比较简单吞吐量较高、延迟较低一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统包括 Clickhouse、Impala等一般支持SQL、不支持事务扩展性比较好可以通过加机器增加数据的存储量响应延迟较长。 还有一类数据库是比较中立的在数据量比较小的时候性能比较好在数据量较大或复杂查询的时候性能也不差一般通过不同的存储引擎和查询引擎来满足不同的业务需求我们把它叫做 HTAPTiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave 半同步支持每周全备每日增量备份。我们做了一些基本功能的增强首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况我们有一个全量库是 300G 数据增量库每天 70G 数据总数据量 700G 左右。我们当时只需要恢复一个表的数据但该工具不支持单表恢复且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作所以我们做了一些优化。例如删减过程中的一些写盘操作减少落盘并将数据处理并行化优化后整库恢复耗时减少到 100 分钟而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时所以我们在使用工具的时候也增加了延时上的考虑实时探测Master-Slave 库之间延时的情况如果延时较大会暂停工具的使用恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善所以我们参照了 MHA 并进行了改动采用 master agent 的方式。Agent 在每一个物理机上部署可以监控这个物理机上的所有实例的状态周期性地向 master 发送心跳Master 会实时监测各个Agent的状态。 如果 MySQL故障会启动 Binlog 补偿机制并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况MHA 的 master 我们也做了高可用设计众多 master 会通过 raft 组成一个 raft group类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力以提供更大容量的数据存储。扩展方式有 SDK例如开源的 ShardingSphere在爱奇艺的使用也比较广泛。另外就是 Proxy开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单扩容难度大依赖较多且运维复杂所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作后端打到 Kafka下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略包括主动探索是否有 SQL 注入及是否存在拖库情况等并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响对此我们进行了一些测试发现使用 General Log 对性能损耗较大有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项再把监控项放到 buffer 里边用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线c;从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线c;运行比较稳定上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据即只需要读写最近一段时间存入的数据过段时间这些数据就不需要了需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式例如 TiDB 或其他 TokuDB两者之间可以进行数据自动搬迁和自动归档同时前端通过 SDK Proxy 来做统一的访问入口。这样一来业务的开发同学只需要将数据存入 MySQL 里读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景虽然 Redis 是一个缓存但我们发现不少的业务同学会把它当做一个 KVDB 来使用在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能启动一个进程伪装成 Redis 的 Slave 实时获取数据再放到后端的 KV 存储里例如 ScyllaDB如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时会由 Sentinel 重新选出一个新的节点成为 Master再把该节点上的数据同步到所有 Slave 上此过程中数据会放在 Master 节点的 Buffer 里如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去重建过程就会失败。 基于这种情况我们对 Redis 告警做了自动化优化如有大量 master - slave 重建失败我们会动态调整一些参数例如把 Buffer 临时调大等 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群如果某个分片发生了故障或者 failoverJedis 就会对所有后端的分片重建连接。如果某一分片发生问题整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis如果某个分片发生故障就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名多个从库绑定读域名。但如果我们进行 Master failover会将读写域名从某旧 Master 解绑再绑定到新 Master 节点上。 DNS 本身有一个超时时间所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的线c;有可能还会连到原来的机器上造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短但对 DNS 服务又会造成很大的压力所以我们在 SDK 上提供 Redis 的名字服务 RNSRNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况如果集群 failoverSentinel 会接到通知客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名通过 IP 地址来访问整个集群屏蔽了 DNS 的超时缩短了故障的恢复时间。 SDK 上还做了一些功能例如 Load Balance 以及故障检测比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦如果客户端已经进行了一定量的分片之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster因为功能受限在爱奇艺应用的不是很多例如不支持显示跨 DC 部署和访问读写只在主库上等。 我们某些业务场景下会使用 Redis 集群例如数据库访问只发生在本 DC我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy读写都通过它来进行。写入数据时 Proxy 会做一个旁路把新增的数据写在 Kafka 里后台启用同步程序再把 Kafka 里的数据同步到其他集群但存在一些限制比如我们没有做冲突检测所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式但存在一些问题。所以数据量较大的时候经验是 160G就不推荐 Redis 了而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少一开始我们是把他当做一个 Memcached 来使用的即纯粹的缓存系统。 但其实它性能还是比较强大的是一个分布式高性能的 KV 系统支持多种存储引擎 (bucket)。第一种是 Memcached bucket使用方式和 Memcached 一样为 KV 存储不支持数据持久化也没有数据副本如果节点故障会丢失数据 第二种是 Couchbase bucket支持数据持久化使用 Json 写入有副本我们一般会在线上配置两个副本如果新加节点会对数据进行 rebalance爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图数据写入时在客户端上会先进行一次哈希运算运算完后会定位 Key 在哪一个 vBucket 相当于数据库里的某个分片。之后客户端会根据 Cluster Map 发送信息至对应的服务端客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新因此客户端对于服务端的 failover 操作不需要做特殊处理但可能在 rebalance 过程中会有短暂的超时导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发最大功能是进行集群间的复制提供多种复制方式单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本正在调研的 6.0中间也遇到了很多坑例如 NTP 时间配置出错会导致崩溃如果每个集群对外 XDCR 并发过高导致不稳定同步方向变更会导致数据丢失等等我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群集群间的数据同步通过 XDCR我们一般配置为双向同步。对于业务来说如果 Cluster 1 写入 Cluster 2 不写入正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障我们提供了一个 Java SDK可以在配置中心把写入更改到 Cluster 2把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高并且数据的存储可以超过内存。但是如果数据量超过内存 75% 这个阈值性能就会下降地特别快。在爱奇艺我们会把数据量控制在可用内存的范围之内当做内存数据库使用。但是它的成本非常高所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB主要使用了其分布式数据库的管理功能增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍又完全兼容 Cassandra 接口设计基本一致可以视为 C 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架例如 C 异步框架 seastar主要原理是在j每台物理机的核上会 attach 一个应用线c;每个核上有自己独立的内存、网络、IO 资源核与核之间没有数据共享但可以通信其最大的好处是内存访问无锁没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时会按照哈希算法来判断请求的 Key 是否是该线程需要处理的如果是则本线c;否则会转发到对应线程上去。 除此之外它还支持多副本、多数据中心、多写多活功能比较强大。 在爱奇艺我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里Value 放在盘上的文件里我们在读和写文件时只需要在内存索引里定位再进行一次盘的 IO 开销就可以把数据读出来相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中如果索引长度较长会限制单机可存储的数据量于是我们通过开发定长的内存分布器对于比较长的 Key 做摘要缩短长度至 20 字节采用红黑树索引限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大截至目前已经替换了 30% 的 Couchbase有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理如果脚本出问题就找 DBA导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案于是在内部构建了一个私有云通过 Web 的方式展示数据库运行状态让业务的同学可以自己去申请集群一些简单的操作也可以通过自服务平台实现解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具比如有业务同学说 MySQL master-slave 延时了DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具出问题时业务的同学可以自己通过网页上的一键诊断工具去排查自助进行处理。 除此之外我们还会定期做预警检查对业务集群里潜在的问题进行预警报告开发智能客服回答问题通过监控的数据对实例打标签进行削峰填谷地智能调度提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起通过经验得出来的一些结论。 对于关系型数据库的选型来说可以从数据量和扩展性两个维度考虑再根据数据库有没有冷备、要不要使用 Toku 存储引擎要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave什么情况下使用客户端分片、集群、Couchbase、HiKV 等我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求但这些都是线f;是否可以通过其他方式把这个需求消耗掉例如在数据量大的情况下可以先做数据编码或者压缩数据量可能就降下来了。 不要把所有需求都推到数据库层面它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么是因为热门吗还是因为技术上比较先进但是不是能真正地解决你的问题如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃当你放弃一个系统时真的是因为不好用吗还是没有用好放弃一个东西很难但在放弃时最好有一个充分的理由包括实测的结果。 ④ 自研 第四是自研在需要自己开发数据库时可以参考和使用一些成熟的产品但不要盲目自研。 ⑤ 开源 最后是开源要有拥抱开源的态度。

利发88