• 关于

    访问透明性出问题什么情况

    的搜索结果

问题

【精品问答】前端开发必懂之CSS技术八十问

茶什i 2019-12-01 22:00:52 1642 浏览量 回答数 1

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。

小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、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 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。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 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 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 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 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、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

租用香港服务器需要注意的三点

网时 2019-12-01 21:46:45 5117 浏览量 回答数 1

回答

最近,我问了我一个朋友他对"智能合约"的看法。他是一名开发者,我想他可能会有一些有趣的见解。令我惊讶的是,他并不知道智能合约是什么。我感到特别惊讶,因为我们讨论了一年多的加密货币、美国证券交易委员会(SEC)以及许多与区块链相关的其他事情。在计算机领域深耕的人怎么可能会不知道智能合约是什么? 事实上,相比区块链行业的其它概念,智能合约可能会更令加密货币爱好者们感到困惑。因此,要解释这个概念并不容易,尤其是向那些刚刚理解区块链是什么的人解释更不容易。因此,这一概念依旧十分神秘。希望这篇文章可以清楚地解释好这一概念。 什么是智能合约? 想象一下,如果你需要卖掉一栋房子,那么这将是一个复杂而艰巨的过程,不但需要处理大量的文书工作、与不同公司和人员进行沟通,而且还得冒着各类高风险。这就是为什么绝大多数房屋卖家决定寻找房地产经纪,来帮助处理所有文书工作、推销房产,并在协商开始时充当中介、监督交易直至交易结束。 此外,该经纪机构还提供委托付款服务,这在此类交易中尤其有用,因为此类交易所涉及的金额通常很大,你将无法完全信任将要与你进行交易的人。然而,在交易成功完成之后,卖方和买方的经纪机构将获得房产卖出价格的7%作为佣金。这对卖方来说是相当大的经济损失。 在这种情况下,智能合约就可以真正派上用场,可以有效地变革整个行业,同时也减少了所需流程。或许最重要的是,智能合约能解决信任问题。智能合约基于"If-Then"("如果-那么")原则,这意味着只有商定的金额被发送到系统时,房屋的所有权才会被转移给买方。 智能合约也可以作为委托付款服务,这意味着资金和所有权都将被存储在系统中,并在同一时间被分发给各参与方。此外,该交易被数百人见证和验证,因此保证了交付是无差错的。由于双方之间不再存在信任问题,因此也不再需要中介。所有房地产经纪能做的都可以预先编程为智能合约,这同时也为卖方和买方节省了大量资金。 这只是智能合约潜在用途的一个例子。智能合约能够帮助货币、财产和其他任何有价值的东西的交易,确保交易过程完全透明,其不但无需中介服务及其附带费用,还消除了双方之间的信任问题。特定智能合约的代码包括了各方商定的所有条款和条件,有关交易本身的信息则被记录在区块链中,即去中心化的分布式公共账本。 智能合约是如何运作的? 简而言之,智能合约很像自动售货机。你只需将所需数量的加密货币放入智能合约中,而你所交易的,房屋所有权等就会自动存入你的账户。所有的规则和处罚不仅在智能合约预先定义了,而且也由智能合约强制执行。 相互依存 智能合约可以独立运行,但也可以与任何其他智能合约一起运行。当它们彼此依赖时,它们可以以某种方式被设置。例如,成功完成一个特定的智能合约可以触发另一个智能合约的启动,依此类推。从理论上讲,整个系统和组织完全可以依靠智能合约运行。某种程度上,这已经在各种加密货币系统中实现了,在这些系统中,所有的规则都是预先定义好的,因此,网络本身可以独立自主地运行。 智能合约的对象 从本质上讲,每个智能合约都有三个不可或缺的部分(也称为对象)。第一个对象是签署方(两方或多方使用智能合约,同意或不同意使用数字签名的协议条款)。 第二个对象是合约的主题。它只能是智能合约环境中存在的对象。或者,智能合约必须可以不受阻碍地直接访问该对象。尽管智能合约早在1996年就被讨论过,但正是这一特定对象阻碍了智能合约的发展。这个问题直到2009年出现第一个加密货币后才得到部分解决。 最后,任何智能合约都必须包含特定条款。这些条款都需要使用数学方法及适用于特定智能合约环境的编程语言进行完整描述。这些条款包括了所有参与方的预期要求以及与所述条款相关的所有规则、奖励与惩罚。 环境 为了使智能合约能够正常运行,智能合约必须在特定的合适环境中运行。首先,智能合约环境需要支持公钥加密,这使得用户能够使用其独特的、专门生成的加密代码来签署交易。这正是绝大多数现有加密货币所用的系统。 其次,它们需要一个开源和去中心化的数据库,合同各方都可以彼此完全信任,并且履约流程完全自动化。此外,为了实现智能合约,整个环境必须自身是去中心化的。区块链,尤其是以太坊区块链,是运行智能合约的理想环境。 最后,智能合约所使用的数据,来源必须完全可靠。这就需要使用根SSL安全证书、HTTPS和其他已经广泛被使用并在大多数现代软件上自动实现的安全连接协议。 智能合约带来了什么? 自治 智能合约消除了对第三方中介的需求,基本上使你能够完全控制合约。 信任 任何人都无法窃取或弄丢你的文件,因为它们已被加密并安全地存储在一个安全的公开账本中。此外,你不必信任你正与之交易的人,也不必指望他们会信任你,因为公正的智能合约系统基本上解决了信任问题。 节约 由于使用了智能合约,你就不需要公证人、房地产经纪人、顾问及其他众多中介机构的援助。这样也就与他们的服务相关的高额费用无关了。 安全 如果智能合约正确执行,它将是极难破解的。此外,智能合约的完美环境受到复杂的加密保护,它可确保你文档的安全。 高效 通过使用智能合约,你将节省通常浪费在手动处理大量纸质文档并将其发送或运送到特定地点等的大量时间。 谁发明了智能合约?谁在使用智能合约? 1996年,计算机科学家和密码学家Nick Szabo首次提出了智能合约。几年后,Szabo重新定义了这一概念并发布了几篇相关文章,他阐述了通过在互联网上陌生人之间设计的电子商务协议来建立合同法相关商业实践的概念。 然而,智能合约的概念直到2009年才被实现,当时第一个加密货币比特币连同它的区块链一齐出现,后者则最终为智能合约提供了合适的环境。有趣的是,Nick Szabo在1998年设计了一种称为比特黄金(Bit Gold)的去中心化数字货币。虽然它没有被实现,但它已经具备了10年后比特币可吹嘘的许多功能。 如今,智能合约主要与加密货币有关。而且,可以公平地说,它们彼此互相依赖,因为去中心化的加密货币协议本质上是具有去中心化安全性的加密智能合约。智能合约现在被广泛应用于大多数加密货币网络中,并且其也是以太坊最杰出和最被大肆宣传的特点之一。 你知道什么是智能合约吗?币圈聚贤庄来跟你分析一下! 智能合约用例 虽然世界各国政府、金融监管机构和银行对加密货币的立场从极其谨慎变成谨慎接受,但加密货币背后的技术,区块链和智能合约,已被广泛认为是具有革命性的,并且正在各个层面实现这些技术。 例如,美国信托与清算公司(DTCC)和四大银行(美银美林、花旗、瑞士信贷和摩根大通)成功地使用Axoni开发的智能合约交易区块链信用违约掉期。智能合约使用了诸如个人交易详情及相应风险指标之类的信息,据一篇新闻稿称,这提高了合作伙伴和监管机构信息处理上的透明度。 类似的事情到处都在发生。由61家日本银行和韩国银行组成的财团一直在测试Ripple的区块链和智能合约,以实现两国之间的跨境资金转移。这一新系统将于今年推出。就连俄罗斯政府控制的俄罗斯联邦储蓄银行(Sberbank),都在俄罗斯这样一个众所周知的反加密货币国家测试以太坊区块链及其智能合约。 测试结果是俄罗斯联邦储蓄银行加入了以太坊企业联盟(EEA),这是一个由100多家企业组成的联盟,其中包括了思科、英国石油、荷兰国际集团(ING)、微软等顶级企业。该联盟旨在开发一种面向商业用途的区块链,用它可以开发和实现这些公司所需的智能合约。 由于智能合约是与加密货币相关联的,因此它们仍主要被应用到金融领域和银行业。尽管如此,世界各国政府都可以使用这项技术,使得投票系统更加便利而透明。供应链可以使用它来监控货物并自动执行所涉及的所有任务和支付。房地产、医疗保健、税收、保险及其他众多行业都可以受益于智能合约的使用。 智能合约的缺点 智能合约仍是一项未成熟的技术,仍然容易出现问题。例如,构成合约的代码必须是完美无漏洞的。它也会出现错误,有时候,这些错误会被欺诈者所利用。就像DAO被黑事件一样,把资金存放在代码有漏洞的智能合约中资金就可能被盗走。 此外,这项新奇的技术也带来了很多问题。政府将如何决定监管此类合约?他们将如何进行征税?如果合约无法访问其主题,或者发生了任何意外情况,将会是什么情况?这是在传统合约签订时可能发生的,传统合同可以在法庭上被撤销,但区块链要求智能合约无论如何都要按照"代码即法律"的规则去执行。 然而,大多数这些问题的存在纯粹是因为智能合约仍未是一项成熟的技术。但这项技术肯定会随着时间的推移而逐渐完善。毫无疑问,智能合约将会成为我们社会不可或缺的一部分。

问问小秘 2019-12-02 03:07:11 0 浏览量 回答数 0

问题

【云能量沙龙深圳站】陆晶丹:阿里云开放存储服务API与Web应用案例分享

sleepbird 2019-12-01 20:27:09 18770 浏览量 回答数 23

回答

《操作系统》课程设计报告课程设计题目:操作系统课程设计 设计时间:2016/1/10一、 课程设计目的与要求需要完成的内容:(1) 安装虚拟机:Vmware、Vmware palyer (free)(推荐)、Virtualbox(推荐)、VMLite、Xen、Virtuozzo、KVM(2) 安装和使用Linux(推荐SUSE)(注意包含内核源码和内核开发工具等)(3) Linux内核源代码配置和重编(4) 找到VFS和一个具体文件系统的源代码(ext3或ext4)(5) 读懂VFS和具体文件系统如何关联(如何体现virtual file switch)(6) 找到具体文件系统的read或write函数,使用printk(使用方法和printf一样)向后台打印文件读写信息。(read或write函数选一个即可)(7) 使用dmesg –c查看后台的输出。可以附加的功能(8) 复制ext3或ext4的源代码(注意与当前使用的文件系统有区别),修改Makefile文件,使用模块编译方式(9) 修改ext3或ext4的源代码,实现新的文件系统。(至少需要修改文件系统的名称,最好能对文件写操作向系统后台打印出信息。)(10) 动态加载和卸载新的文件系统。二、 课程设计内容(1) 安装虚拟机(2) 安装和使用Linux(3) Linux内核源代码配置和重编(4) 提取并动态加载和卸载新的文件系统三、 课程设计设备与环境设备信息:PC 虚拟机:VM11 四、 设计正文(包括分析与设计思路、各模块流程图、带注释的主要算法源码、内核编译过程以及动态模块加载过程等,如有改进或者拓展,请重点用一小节进行说明)(1) 安装虚拟机(2) 安装和使用Linux(推荐SUSE)(注意包含内核源码和内核开发工具等)安装OpenSUSE,并下载相近版本的内核源码 初始内核版本 下载的源代码包 (3) Linux内核源代码配置和重编利用vmtools(虚拟机提供的可以在宿主机和虚拟机之间自由复制文件的工具)将内核源码包复制进虚拟机,解压到/home/a123/linux-3.12.51 *因为分配的磁盘空间比较小,所以没有按照惯例把内核源码放在/usr/src目录下(如果放在这里,会出现空间不足的情况)附:磁盘分配情况/swap(交换分区) 2.4G/(根目录) 11G/home(用户目录) 13G 解压好的内核源码文件在编译前需要稍作修改(6),并且缺乏一个config文件告诉编译器编译哪些功能。Config文件可以用make menuconfig命令生成,但是需要自己选择相应的功能,太过复杂,这里有一个简便的方法因为下载的内核源码是相近的版本,所以可以使用现有版本的config文件,该文件在/boot目录下使用cp /boot/config-3.11.6-4-desktop .config命令将此文件复制过来 注意:应当在内核所在的文件目录下使用此命令复制成功 执行 make menuconfig命令,进入选择界面,直接保存退出即可虽然新版本的Linux可以直接执行make一步完成所有的编译工作,但此次课程设计仍然采用以前的编译的方式 执行 make bzImage命令——编译压缩的内核编译完成 执行 make modules命令——编译模块 执行 make modules_install命令——安装模块 注: 在make menuconfig时我在General setup中把版本号改过 执行 make install命令——安装新内核 Reboot重启 说明内核修改安装完毕,成功(4) 找到VFS和一个具体文件系统的源代码(ext3或ext4)VFS:虚拟文件系统,顾名思义。它为应用程序员提供一层抽象,屏蔽底层各种文件系统的差异。Linux的文件系统采用面向对象的方式设计,这使得Linux的文件系统非常容易扩展,我们可以非常容易将一个新的文件系统添加到Linux中。在此主要对象之一super_block位于中 代码量巨大,此为部分代码Ext4在fs文件夹下的ext4文件夹内 此处打开file.c用vim打开file.c部分代码如下 (5) 读懂VFS和具体文件系统如何关联(如何体现virtual file switch)在(4)中已经提到,VFS是C语言写的一个面向对象的设计,比如我们要调用alloc_inode方法:sb->s_op->alloc_inode(sb)。这里与面向对象语言的差别是,面向对象语言里实例方法可以访问到this,这样就可以访问到自身的所有成员,但是在C里却做不到,所以需要将自身作为参数传入到函数中、图一表示了对文件写操作的调用过程 (6) 找到具体文件系统的read或write函数,使用printk(使用方法和printf一样)向后台打印文件读写信息。(read或write函数选一个即可)因为Linux系统对文件的操作是通过函数调用来实现的,所以在此我修改的是vfs这一层,找到fs,目录下的read_write.c并打开找到do_sync_read函数,在其返回前加入printk语句 (7) 使用dmesg –c查看后台的输出。 (8) 复制ext3或ext4的源代码(注意与当前使用的文件系统有区别),修改Makefile文件,使用模块编译方式 (9) 修改ext3或ext4的源代码,实现新的文件系统。(至少需要修改文件系统的名称,最好能对文件写操作向系统后台打印出信息。) 使其在加载和卸载的时候能够printk到buffer缓冲中(10) 动态加载和卸载新的文件系统。使用insmod语句加载使用lsmod语句加载 加载成功接下来使用dmesg 查看缓冲区内容 成功接下来使用rmmod语句卸载模块 成功五、 课程设计结果及分析课程设计结果:成功分析:Linux文件系统使用了面向对象的设计方法,保证了其对用户的透明,VFS层实现了系统与文件系统的无关性,增加了系统对不同文件系统的兼容性。六、 总结与进一步改进设想总结:1.编译内核的时候,可以使用make XXX –j8这样可以开启多线程编译(我的虚拟机分配的是8核心),加快编译速度2.printk语句我写的是printk(”””DoingRead”);本意是利用printk的优先级,将其输出到用户态的控制台,结果语法错误,并没有输出到控制台改进设想:修改的文件前加上语句,实现对控制台的输出 define KERN_EMERG 0(因为缺少这个宏,导致系统并没有理解我的0是什么意思) 七、 答辩(或汇报)记录(包括问题和答案,每个人不少于3个) 显示内核版本 使用dmesg –c命令 加载新模块 八、 参考文献 鸟哥的Linux私房菜 百度百科:printk概述http://baike.baidu.com/link?url=Kv5e2xb9thGENkIvSQmjpkYb8kbKoNvEhmt2oICTmDAn0wj2YADVf8dsrzBtz2fRt0uwa_3joQ-o40wKwwL68a Linux虚拟文件系统(VFS)http://www.cnblogs.com/yuyijq/archive/2013/02/24/2923855.html LinuxEXT4文件系统分析http://wenku.baidu.com/link?url=Wi-vyrROUIJqRk4eSsuwOwRe0Sf-ydXamWNR0H2HCrN9CPHJg80lXpu0Gi_ZGT-X5yKnknl86ooHdckHhJxybmyBR2szWsPDOV0IPJ6fJXO

杨冬芳 2019-12-02 03:10:35 0 浏览量 回答数 0

回答

燃财经(ID:rancaijing)原创 作者 | 唐亚华 编辑 | 魏佳 春节临近,一年一度人口大迁移又要来临。 虽然12306近日已经宣称屏蔽了部分抢票软件,并推出官方候补功能,但市面上提供抢票服务的仍然有智行火车票、 高铁管家、携程、美团、飞猪、同程艺龙等60多个软件。 不过,多名用户反馈称“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票。技术专家告诉燃财经,从原理上来说,抢票软件只是将用户手动购买车票的链路照搬,用机器来操作,利用企业带宽和机器速度来当“代购”。购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。但是,能不能抢到票仍然是概率问题。 即便如此,仍有众多抢票软件在加速包、VIP会员、优先出票权、安心抢等名目上“动脑筋”,燃财经测试发现,如果要一步一步升级到“抢票顶配”,在携程上需要花费138元,在美团上需要花费80元。这也让不少人诟病抢票软件有捆绑、诱导消费之嫌。 事实上,抢票难的根源在于春节这样短期的大规模迁徙带来的巨大需求缺口难以满足,消费者能做的就是谨慎选择、找准时机、注意捡漏及多种方式搭配。在巨大的需求之下,抢票软件和其商机也将长期存在,但套路不是长久之计,真正为用户提供价值才能让人继续买单。 抢票是一门玄学 自2019年12月12日进入春运以来,“我在XX抢票,快来帮我加速。皮皮虾,我们抢”、“为我回家助把力”、“你不点我不点,小X回家有危险”的文案又开始出现在各大微信群,为抢票助力和“砍一刀”都成了大家考验人缘的方式。 尽管不久前12306对外表示已经屏蔽了多个抢票软件,但燃财经了解到,智行火车票、高铁管家、携程、美团、飞猪、去哪儿、同城艺龙等60多家平台仍然推出了抢票功能。 不过,这一次,用户的反馈不同以往,结合论坛中网友的反馈和燃财经的采访情况,大家普遍反映“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票,这也引发了大家对于春运抢票加速包是“真有用”还是“智商税”的讨论。 用户小黎告诉燃财经,他在智行火车票上预约了春节回家的火车票,放票时间一到,抢票软件一直显示“抢票中”但并没有成功。心急之下,他自己登上12306官网,发现显示还有余票,很顺利就买上了。“我怀疑不买加速包,抢票软件是不是根本就不给抢。” 另一位用户张宇在智行火车票、携程、美团都提交了抢票订单并购买了40元极速抢票服务,连续抢了三天仍然没有抢到北京到日照的车票。她表示,前几年用抢票软件都能挺顺利抢到,这一次有点失望。 “这两天我用飞猪抢票,加了30元手续费。从放票开始,我就一直守在手机、电脑前。结果飞猪软件里一直显示无票。我又去贴吧看,发现有人在12306官网买到票了,但飞猪还是显示无票。花了30元的VIP手续费,自始至终没看见显示有票,还不如免费抢票软件。”某网友感叹。 抢票软件套路多 尽管抢票软件的效果不能保证,但套路还不少。 燃财经体验了智行火车票、携程、美团、飞猪等平台的抢票后发现,各大平台的抢票方式大同小异,总体感受是不用加速包、不买VIP基本抢不到票,但买了也不承诺能抢到。因为各平台的规则不透明,没有一家承诺100%抢到票,只会提供预估成功率,而这个成功率到底是70%还是98%,在用户端感知不到差异。 总结来看,抢票软件大致有以下几种套路。 首先是用不明显的字体颜色诱使用户购买“加速包”或VIP会员。如下图携程和美团的购票页面上,要购买加速包的“极速购票”用红色字体,不用加钱的“低速抢票”则是不明显的浅灰色字体,不仔细看的用户有可能不小心勾选付费极速抢票的选项。燃财经在测试时,就差点没找到免费的抢票选项。 另外,在文案上制造焦虑也是常见的方式。“低速抢票难度很高,很可能失败”、“低速度抢票成功率52.2%,极速抢票成功率68.86”、“52%的加速用户选择光速抢票”等提示,很容易给用户制造出一种不用加速包、不花钱就抢不到票的焦虑。 第三,平台会不断提醒用户升级加速包,用上了抢票软件就开始一步一步走入它们的套路中。 抢票软件的抢票速度分为低速、快速、高速、极速、光速、VIP,如果你先选择了低速的免费抢票,系统会显示“邀请好友来助力,最高升至光速抢票”,此时,邀请好友点击助力、看广告就是平台的用意。 而当票没抢到时,页面上会有多个提示你升级的选项,燃财经尝试在各平台上都选择了40元极速抢票,本以为高枕无忧了,没想到这才是个开始。如携程还设置了“优先出票特权:发现余票将优先为你出票,10元/人”、“开通超级会员,免费升级VIP抢票,88元/年”,燃财经计算发现,如果直接开通超级会员需要88元,而一步一步升级到抢票顶配,预计需要加138元。 在美团上选择了40元极速抢票后,系统提醒还差10分加速包升至光速抢票,成功率59%,10元/人,VIP抢票成功率61%,30元/人,想升级到顶配需要80元。智行火车票显示从低速到中速、快速、高速、极速、VIP分别需要10元、20元、30元、40元、50元。 另外,去哪儿旅行上还有“安心抢”、“请朋友帮我挂机”、“购买抢票年卡,72元享3次VIP抢票”等选项,而邀请朋友助力时,软件会获取用户的位置、手机号等信息。 最后,尽管有一些抢票软件承诺抢不到票全额退款,但抢票软件会提示用户勾选更多车次、更多时间、跨站抢票以提升抢票成功概率,最终用户买到的并不是“最优选”,但也无法退费。 以上这些套路也是用户吐槽投诉的重灾区。黑猫投诉上有152条关于抢票软件的投诉,例如“智行火车票二次收费”、“同城艺龙购票98%的成功率却抢不到票”、“高铁管家强制套餐消费”等,多是抢票软件诱导消费、退费难的问题。 众多抢票软件的存在,事实上提高了所有人的抢票门槛。这些五花八门的加速选项,增加消费者的筛选成本,抢到了是运气,抢不到只好自认倒霉。 另外,不少APP存在个人信息泄露的风险。抢票软件作为一个工具类插件,技术开发上的门槛较低,用户输入12306的网站用户名、密码等个人信息被传到平台服务器后,如果安全保护性太低,个人信息很容易被泄露。 抢票软件等于外挂 能不能抢到是概率 抢票软件的加速包真的有效果吗,背后的技术原理又是什么呢? 径点科技首席架构师张英辉告诉燃财经:“我们去12306买票的时候要输入信息、查询、购买,所有的抢票软件都是基于同一种原理,将这些手动操作的步骤用程序来实现,然后不停重试。在用户手速和刷票频率的局限下,第三方抢票平台利用机器刷票、全自动化处理有其优势。” 他还提到,购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。因为消费者大多使用的是普通4G以及20M光纤宽带,跟平台使用的企业级宽带的网速自然是不能相比的,在这个拼速度的模式里,抢票软件集合了企业宽带和机器速度的“代购”,就相当于打游戏的时候加了外挂。 整体来看,刷得越勤,用的服务器越多,抢中票的概率越大,但在实际操作中能不能刷中,可能要看那一秒的时间窗口。“因为市面上有60多个刷票软件,某一趟车从一个站到另外一个站的余票情况随时都在变,这种情况下,谁能刷中不一定,取决于刚好出票这一秒哪个软件在刷。”张英辉强调,抢票软件并不能增加车票,12306系统上没票的时候,再多的加速包都没用。 这个过程中还有12306和抢票软件之间的攻防博弈战。 张英辉指出,从技术上来说,12306后台能检测出刷票软件,如果刷票带来的负担超过网站的负荷,后台通常会限制这样的账号,同一IP地址刷票过于频繁或同一购买请求提交过于频繁,都有可能被拖入慢速或被屏蔽掉。但至于具体是什么限流规则,是由12306来制定、调整和实施。 当然,被屏蔽后的刷票软件可能会通过更换IP地址、使用多台服务器轮流操作等方式规避检测。刷票软件也在持续研究怎样绕过官方规则,双方在不停地博弈。所以用户用抢票软件没买到票,可能是因为没刷到,也可能是刷票软件被屏蔽了。 中国铁道科学研究院12306技术部主任单杏花在2019年接受媒体采访时表示,12306已经对第三方抢票软件的相关特征进行识别并实施了流量拦截,即使用户花钱购买了第三方抢票平台的加速服务,购票的成功率也会大打折扣。另外,12306已经推出了“官方抢票”的候补功能,如果遇到有旅客退签返回的车票,或者是铁路方面根据列车能力情况加挂而增加的车票,就可以优先配给已经排队等候的人。 “刷票软件本身的技术难度不大,市面上甚至有很多免费刷票程序或源代码,稍微懂点的人自己都能安装刷票,但要想把刷票功能做得强大很难。要支持大量用户的需求,又要避开12306的监管,可能就需要投入更多的服务器、人力。说白了,给一个人低速刷票很容易,给100万人快速刷票就会变得复杂。”另一位技术人士李元表示。 从理论上说,平台需要投入设备、人力,完成抢票工作后,收取额外的资源占用费是合理的。张英辉认为,问题在于抢票软件在提高概率的同时也提高了买票者的心理预期,一些花了钱没有达到目的的人就会有负面反馈。用户期望交了钱就买到票,但这明显是个概率模式,必然会出现有的刷得到、有的没刷到的情况。 抢票难题和抢票软件将长期存在 经常有人说,微信几亿人同时在用,双11的时候淘宝那么大的流量都能正常运转,12306为啥连个买票软件都做不好? 张英辉解释,12306的业务逻辑要远远比微信和淘宝复杂得多,比如一辆列车经过,中间是十几个站,不停地有人下有人上,还有人换乘,之间有几百种可能性,系统库存随时在变。如果微信有一条消息没发出去或者发了两次是小事,但一张票如果卖给了两个人,这是重大失误。 另外,12306的库存变化又受到网站、APP、售票厅、自动售票机等多方的实时变动影响,用户需求又有时间、车次、地点的无数种排列组合情况,且整个路程在短时间内就要完成,还要验证用户身份以排除同一车次同一人的重复购买,市面上的众多抢票软件还增加了12306的数据压力,系统无论从技术的完整性和资源调度上都远远比微信和淘宝的业务复杂得多。 他还指出,12306最开始采购的应用可能能够支撑平时1亿人访问,但是到了春节期间,有几亿人同时访问,后台需要采购的设备也不是一时就能实现的,购买、部署、调试等整个周期环节就很长,但春节以后又没有那么大的流量了,硬件折旧损耗,人力维护成本都会浪费,所以12306如果只是为了春运和几个大的节假日去加技术和硬件,实际上也是不可行的。 说到底,铁路总运力是一定的,春运这个非常态的需求是极其巨大的,抢票软件并不能增加供给,也不会提高整体买到票的概率,抢票难的根本原因是供求关系不平衡。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区

茶什i 2020-01-08 11:53:49 0 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:01 0 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:00 0 浏览量 回答数 0

问题

词汇表是什么样的?(S-V)

轩墨 2019-12-01 22:06:08 2089 浏览量 回答数 0

回答

ReFtp4oss(只需配置、不用写代码)完美兼容DiscuzX、phpwind、wordpress等网站 Ftp4oss 官方网址:http://www.ftp4oss.com/   2013年阿里云开发者大赛 决赛20强作品,欢迎大家的支持!非常感谢! Ftp4oss是目前阿里云生态环境中已提供的 最简单的OSS专用的FTP服务;只需10分钟配置、不用写代码,普通站长即可快速地使用上阿里云OSS云存储的一个应用级FTP服务,同时提供安全的FTP快速中转服务,符合OSS云安全理念! 1、上传文件快速无延时、无停顿感(仅受限于用户家庭ADSL的上传瓶颈)! 2、完美兼容DiscuzX、phpwind、wordpress等网站系统(这里有各种演示和试用哦 ),理论上支持所有设计有远程附件的FTP站点, 网站升级再也不用发愁了! 3、不用服务器环境配置、不用看黑界面、不用安装程序……都不用,只需要网站注册账户、三步网站操作获得FTP服务、远程附件配置即可! 4、……还有各种优势等您去帮大家发现! 快来选择Ftp4oss吧!请点击www.ftp4oss.com  详细了解,并使用FTP for OSS服务吧! 注册Ftp4oss账户 三步网站操作,10分钟快速拥有FTP服务: 第一步:输入OSS Access Key和Access Secret; 第二步:选择Bucket或者新创建一个Bucket; 第三步:输入Ftp用户名和Ftp密码; 即可获得FTP服务,立即用FlashXP、FtpRush、FileZilla等客户端软件登录测试(能创建文件夹、上传文件夹、上传文件等) 下图所示: 测试左侧上传一个文件,然后在右侧的上部您是 看不到该文件(但是文件已经成功到OSS了)的(故而您也无法做出删除操作),但是您可以从右下部显示的文件已经成功上传到OSS上了,您可以点击该URL链接来查看! 把Ftp4oss服务应用到您的爱站,详细配置可参考:http://www.ftp4oss.com/help/UsefulSitesHelp.htm —————————————————————————————————————————————————————————— 1、安全的云FTP 考虑到OSS的安全特点,我们特意屏蔽了部分FTP功能,比如默认账户权限只具有创建文件夹、上传文件、删除文件等功能,但是屏蔽了危险的删除文件夹等操作——这些功能已经能满足市面常见网站系统的远程附件要求,同时避免账号泄漏带来的风险; 2、网站用户登录安全:网站的介绍页面采用静态发布,而用户登录、账户管理等交互页面采用SSL的Https安全协议,尽最大努力保护用户的信息安全; 3、关键信息加密:用户口令MD5不可逆加密传输与保存,用户的OSS Access密码采用动态密钥加密后存储,数据库连接字符串加密,即使网站数据库被黑客入侵也无法获得用户的关键信息; 4、高性能缓存转换:针对ECS的磁盘性能低效情况,我们首创缓存转换设计,即在FTP上传文件过程中,直接保存该文件流到缓存中,并不写入系统磁盘,而是缓存转换后通过OSS的SDK直接传到OSS上,实现高性能设计; 注:用户—站长的网站—Ftp4oss—OSS各角色之间的关系,其中红色背景的是Ftp4oss. Ftp4oss程序实现了基本的FTP服务器的功能,监听网站服务器的FTP连接请求,当普通用户向网站提交图片、附件的时候(注1), 网站服务器接收后会及时自动的通过FTP连接、发送到Ftp4oss服务器(注2), Ftp4oss程序即刻应答并接收该文件,并通过OSS的SDK同步到OSS上(注3), 这个过程就是用户上传图片到网站服务器后通过Ftp4oss同步到OSS的过程,整个过程对于用户来说是透明的,由于阿里云内网时延低、带宽在2G以上,所以对于用户上传一张1M的图片多耗费的时间均在1秒以内,其时间等候体验基本是相同的。 当用户访问网站的时候,直接下载了网站服务器的网页内容,该网页的图片、附件则直接从OSS高速下载到用户的浏览器上(注4); ------------------------- ReFtp4oss(只需配置、不用写代码)完美兼容DiscuzX、phpwind、wordpress等网站 我们欢迎阿里云ECS、OSS、RDS等各种为站长网站服务的作品与我们合作,大家互相支持、互相推广,更好的为广大站长们提供一体化解决方案! 首先,我们欢迎OSS的客户端工具与我们合作推广,希望您作品成熟、功能完善,安装部署简单! 因为我们的作品是专门为网站的远程附件服务的,所以特意屏蔽了FTP的部分功能,所以站长无法通过FTP客户端软件完全管理OSS上的文件(即使我们开放了FTP的所有功能,其效率也是如果OSS客户端软件直连OSS的效率高) 所以, 我们欢迎OSS工具的作者与我们合作,您不一定能给我们带来用户,但是我们是肯定可以为您带去用户的!   其它作品作者也欢迎与我们合作推广! http://www.ftp4oss.com/ 首页底部有联系我们的方法! ------------------------- 回4楼mrznz的帖子 非常感谢版主的支持! 您的建议“为附件添加HTTP头信息 Expires与Cache-control的选项”我们会加入下一步的改进计划(如果OSS的C# SDK有支持的话)~~~ ------------------------- 回7楼mayle的帖子 接受版主的批评~~~ 另:我们的产品确实已经上线,我们在提交阿里云审核的时候,已有一个多月的内测了(主要针对的是Disucz和phpwind系统) ------------------------- 回8楼cuinew的帖子 谢谢老兄的支持! ------------------------- 回6楼牛逼王的帖子 谢谢支持~~~ ------------------------- 回12楼cuinew的帖子 嗯,这个问题确实存在,某些逻辑未处理好,我们会改进的,下一个版本将解决这个问题~~~ ------------------------- 回14楼susan20120530的帖子 谢谢管理员的支持!非常感谢! ------------------------- 回23楼mrznz的帖子 您放心,HTTP头的信息添加这两天就放出来了; 本次更新的内容较多,加上这周有3天时间出差到上海参加了华为的云计算世界大会耽搁了点时间 预计您提的建议,明天晚上可以完成,我们测试没问题 后联系你~~~ ------------------------- 回22楼kylin30的帖子 谢谢您的夸奖~~~这让我们有更多的动力把Ftp4oss做的更好~~~ ------------------------- Re第111号作品:Ftp4oss(只需三步网站配置,不需配置环境、不用写代码) 顶起来,希望得到大家的支持哦~~~ ------------------------- 回30楼daigoubu的帖子 确实很方便,感谢支持! ------------------------- 回31楼司徒尔特的帖子 信息不详细者或者无法联系上的,均不能通过审核~~~~ 为了保障服务,初步了解用户站点请求压力情况和避免恶意注册占用资源,才增加了信息审核一关,请放心使用,感谢支持~~~ ------------------------- 回36楼孤独小超的帖子 您好,Ftp4oss目前推出的 FTP云服务和FTP云工具一直都是免费的呀,包括即将推出的Linux版本云工具和OSS客户端等产品也都将是免费的,并且今后也将持续提供这些免费产品来满足大部分用户的使用; FTP云服务的免费的单文件上传大小限制 故意比 FTP云工具的要小,目的就是尽量引导有需要的用户使用FTP云工具,这样可以减轻我们的服务器压力。 部分增值功能预留给收费版本也是为了将来有一点点收入来维持我们的持续研发和运维; 很多用户支持收费说只有收费才能信任我们的产品和服务,但是也有一部分用户反对我们收费,希望提供全功能的免费产品,这对我们真是一个两难的选择啊;这两个极端是实事,我们也理解. ------------------------- 回38楼孤独小超的帖子 FTP云工具链接OSS的方式,是由用户自由设定的; 如果设定由内网通信,则该工具必须运行在对应的ECS服务器上;如果设定外网通信,则运行物理位置不限制; 如您的需求为了省下流量费用,则可以把FTP云工具设置为内网模式,并运行在对应节点的ECS服务器上,那么上传、下载(下载功能在新版本会提供)确实不占用OSS的外网流量; 您可以到基础工具频道下载一个试用看看,谢谢您的支持! ------------------------- 回44楼老残的帖子 您好,感谢支持啊 Linux版本的Ftp4oss云工具快完成了,目前进度在跨Linux版本运行上存在点问题,我们尽快解决; 原来计划年内发布,现在看样子得推迟到年后再发布了~~~ ------------------------- 感谢支持~~~ ------------------------- 回47楼老残的帖子 很可能是你粘贴的IP、用户名或者密码两端存在空格引起的~~~~ 你加我们的技术客服QQ 1487960688 ,人工协助你看一下问题原因~~~ ------------------------- 回51楼老残的帖子 能用了就好 ------------------------- 回 53楼(centaurus) 的帖子 支持Linux系统的版本从月初延迟到月底,不过本周已经开始内测了,计划本周末开始邀请部分Ftp4oss用户一起测试,测试结束后,完善程序后即可发布。有望在3月上旬发布,敬请期待! ------------------------- 回 54楼(疯少) 的帖子 您好,请问您用的是哪一套网站系统?目前使用的是Ftp4oss的哪一个产品(FTP云工具还是FTP云服务?) 如果方便的话,请加我的QQ 1487960688 ,我来帮你定位故障的原因~~~ 感谢您的支持! ------------------------- 回 58楼(yxfwz) 的帖子 您好,您可以加QQ 1487960688 反映注册情况哦 一般我们都是在1--2天之内完成审核工作的。另外,如果你注册的是FTP云工具类型的账户,则无需审核即可直接登录软件了; http://bbs.aliyun.com/read/152856.html ------------------------- 顶起啦,希望大家多多支持! ------------------------- 回 65楼(薇薇luo) 的帖子 你的ftp4oss注册通知邮件里面有客服QQ,你可以联系一下 ------------------------- 2014年6月19日(应该是5月28日才对)更新,请点击:  [分享]发布:支持OSS的FTP云工具稳定版V1.0(Linux版——Ftp4oss出品) ------------------------- 回 71楼(amu) 的帖子 你好,FTP云服务(在线的FTP服务)为了尽量的提高安全性,所以设计上屏蔽了文件列表显示,但是整体功能并不影响网站远程附件的使用; 如果您是人工操作OSS的话,现在你可以有两种选择: 1、选择使用FTP云工具——类似FTP云服务,但是增加了文件列表、下载、删除等功能; 支持OSS的FTP云工具Linux版本 http://market.aliyun.com/product/12-121590002-cmgj000207.html 支持OSS的FTP云工具Windows版本 http://market.aliyun.com/product/12-121590002-cmgj000208.html 2、选择使用OssExplorer——OSS的专用客户端,方便OSS上的文件管理! [分享]OssExplorer(OSS专用客户端)http://bbs.aliyun.com/read/161263.html ------------------------- 回 75楼(nydalu) 的帖子 您好,可以联系我们技术客服的QQ,以便协助你找一下原因~~~ 这个是我们刚刚通过Ftp4oss上传了png图片的一个效果,请你查看 http://ftp4oss.oss-cn-hangzhou.aliyuncs.com/2011121417032133245.png 我们这边测试是正常的哦 ------------------------- 回 77楼(cbiz100) 的帖子 您好,近期阿里云ECS增加了很多Linux版本,我们还未做兼容性测试; 详细的系统支持请见介绍: http://market.aliyun.com/product/12-121590002-cmgj000207.html?spm=0.0.0.0.cceFhh#user_comments 1、你这里提到的是32位系统,请你下载32位版本自行测试看看,不一定兼容;(下载和配置地址 http://bbs.aliyun.com/read/154294.html?spm=5176.7189909.0.0.tuCDe9) 2、目前的FTP云工具只能支持一个账号而已(下一个升级版本有考虑到这个多用户的支持); 3、近期还不能支持七牛。 您可以更简单的选择我们的FTP云服务,对系统不作要求,直接使用我们提供的在线FTP云服务。 ------------------------- [分享]★★★   OssExplorerOSS客户端正式发布了——Ftp4oss出品 ------------------------- 回 83楼(云通) 的帖子 你好,你说的Linux版本是哪个工具呢? ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. www.ftp4oss.com 现更改为 www.ct.cc   "Ftp4oss团队"现更名为"CT团队" ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 支持支持! ------------------------- 回 87楼(晓庄) 的帖子 当然可以修改产品类型了,我们的帐号注册后通行我们开发的所有产品~~~ ------------------------- 回 89楼(晓庄) 的帖子 估计是您的注册信息缺失太多,导致未能通过审核,虽然不影响您的工具类产品的使用,但是无法登陆网站; 您可以联系我们的QQ技术(到www.ct.cc获取联系方法)协助您处理,审核通过后即可登陆网站更新类型了; ------------------------- 回 90楼(itdashen) 的帖子 联系我们的QQ技术(到www.ct.cc获取联系方法)协助您查看原因! ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 不同的工具采用不同的SDK,也有直接自己封装API的; ------------------------- 回 96楼(bigoo) 的帖子 如果你的文件夹555下有图片的话,那么你直接FTP上传图片或者整个文件夹的话,肯定是没有问题的,这个只是最最基本的功能而已! 根据你的描述,很可能你连接的FTP很可能只是你自己的传统FTP服务器,而不是我们提供的Ftp4oss~~ 建议发个FTP连接IP的截图看看,如有需要,也可以请联系技术QQ 1020736080 协助你看看~~~ ------------------------- 回 98楼(bigoo) 的帖子 你的这么多截图都看不到重点的交互,你的楼上也给你留了协助联系方式,不过你也没联系,我们也联系不到你,呵呵;论坛帖子留言是反馈问题,不是解决问题的最佳方式~~~ 我们的Ftp4oss一年多了用户反映兼容性还是不错的,期待你能和我们联系,可以和你一起看看你那边有什么特殊的情况; ------------------------- 回 101楼(晓庄) 的帖子 你好,FTP云服务默认给的是10M的全局大小;而FTP云工具默认是2M,采用Ftp4oss帐号登陆则默认为10M,还可以免费授权大于10M的上传; ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 楼上用户已联系技术客服沟通完毕; 说明:现有的FTP云服务支持10M以下的文件上传,需要传输大小10M的文件,需要选用FTP云工具;

ftp4oss 2019-12-02 02:03:28 0 浏览量 回答数 0

回答

简介 ES是一个基于RESTful web接口并且构建在Apache Lucene之上的开源分布式搜索引擎。 同时ES还是一个分布式文档数据库,其中每个字段均可被索引,而且每个字段的数据均可被搜索,能够横向扩展至数以百计的服务器存储以及处理PB级的数据。 可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。 ES就是为高可用和可扩展而生的。一方面可以通过升级硬件来完成系统扩展,称为垂直或向上扩展(Vertical Scale/Scaling Up)。 另一方面,增加更多的服务器来完成系统扩展,称为水平扩展或者向外扩展(Horizontal Scale/Scaling Out)。尽管ES能够利用更强劲的硬件,但是垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展,通过向集群中添加更多的节点来分担负载,增加可靠性。ES天生就是分布式的,它知道如何管理多个节点来完成扩展和实现高可用性。意味应用不需要做任何的改动。 Gateway,代表ES索引的持久化存储方式。在Gateway中,ES默认先把索引存储在内存中,然后当内存满的时候,再持久化到Gateway里。当ES集群关闭或重启的时候,它就会从Gateway里去读取索引数据。比如LocalFileSystem和HDFS、AS3等。 DistributedLucene Directory,它是Lucene里的一些列索引文件组成的目录。它负责管理这些索引文件。包括数据的读取、写入,以及索引的添加和合并等。 River,代表是数据源。是以插件的形式存在于ES中。  Mapping,映射的意思,非常类似于静态语言中的数据类型。比如我们声明一个int类型的变量,那以后这个变量只能存储int类型的数据。比如我们声明一个double类型的mapping字段,则只能存储double类型的数据。 Mapping不仅是告诉ES,哪个字段是哪种类型。还能告诉ES如何来索引数据,以及数据是否被索引到等。 Search Moudle,搜索模块,支持搜索的一些常用操作 Index Moudle,索引模块,支持索引的一些常用操作 Disvcovery,主要是负责集群的master节点发现。比如某个节点突然离开或进来的情况,进行一个分片重新分片等。这里有个发现机制。 发现机制默认的实现方式是单播和多播的形式,即Zen,同时也支持点对点的实现。另外一种是以插件的形式,即EC2。 Scripting,即脚本语言。包括很多,这里不多赘述。如mvel、js、python等。    Transport,代表ES内部节点,代表跟集群的客户端交互。包括 Thrift、Memcached、Http等协议 RESTful Style API,通过RESTful方式来实现API编程。 3rd plugins,代表第三方插件。 Java(Netty),是开发框架。 JMX,是监控。 使用案例 1、将ES作为网站的主要后端系统 比如现在搭建一个博客系统,对于博客帖子的数据可以直接在ES上存储,并且使用ES来进行检索,统计。ES提供了持久化的存储、统计和很多其他数据存储的特性。 注意:但是像其他的NOSQL数据存储一样,ES是不支持事务的,如果要事务机制,还是考虑使用其他的数据库做真实库。 2、将ES添加到现有系统 有些时候不需要ES提供所有数据的存储功能,只是想在一个数据存储的基础之上使用ES。比如已经有一个复杂的系统在运行,但是现在想加一个搜索的功能,就可以使用该方案。 3、将ES作为现有解决方案的后端部分 因为ES是开源的系统,提供了直接的HTTP接口,并且现在有一个大型的生态系统在支持他。比如现在我们想部署大规模的日志框架、用于存储、搜索和分析海量的事件,考虑到现有的工具可以写入和读取ES,可以不需要进行任何开发,配置这些工具就可以去运作。 设计结构 1、逻辑设计 文档 文档是可以被索引的信息的基本单位,它包含几个重要的属性: 是自我包含的。一篇文档同时包含字段和他们的取值。 是层次型的。文档中还可以包含新的文档,一个字段的取值可以是简单的,例如location字段的取值可以是字符串,还可以包含其他字段和取值,比如可以同时包含城市和街道地址。 拥有灵活的结构。文档不依赖于预先定义的模式。也就是说并非所有的文档都需要拥有相同的字段,并不受限于同一个模式 {   "name":"meeting",   "location":"office",   "organizer":"yanping" } {   "name":"meeting",   "location":{     "name":"sheshouzuo",        "date":"2019-6-28"   },   "memebers":["leio","shiyi"] } 类型 类型是文档的逻辑容器,类似于表格是行的容器。在不同的类型中,最好放入不同的结构的文档。 字段 ES中,每个文档,其实是以json形式存储的。而一个文档可以被视为多个字段的集合。 映射 每个类型中字段的定义称为映射。例如,name字段映射为String。 索引 索引是映射类型的容器一个ES的索引非常像关系型世界中的数据库,是独立的大量文档集合。   关系型数据库与ES的结构上的对比 2、物理设计 节点 一个节点是一个ES的实例,在服务器上启动ES之后,就拥有了一个节点,如果在另一个服务器上启动ES,这就是另一个节点。甚至可以在一台服务器上启动多个ES进程,在一台服务器上拥有多个节点。多个节点可以加入同一个集群。 当ElasticSearch的节点启动后,它会利用多播(multicast)(或者单播,如果用户更改了配置)寻找集群中的其它节点,并与之建立连接。这个过程如下图所示: 节点主要有3种类型,第一种类型是client_node,主要是起到请求分发的作用,类似路由。第二种类型是master_node,是主的节点,所有的新增,删除,数据分片都是由主节点操作(elasticsearch底层是没有更新数据操作的,上层对外提供的更新实际上是删除了再新增),当然也能承担搜索操作。第三种类型是date_node,该类型的节点只能做搜索操作,具体会分配到哪个date_node,就是由client_node决定,而data_node的数据都是从master_node同步过来的 分片 一个索引可以存储超出单个结点硬件限制的大量数据。比如,一个具有10亿文档的索引占据1TB的磁盘空间,而任一节点都没有这样大的磁盘空间;或者单个节点处理搜索请求,响应太慢。   为了解决这个问题,ES提供了将索引划分成多份的能力,这些份就叫做分片。当你创建一个索引的时候,你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”,这个“索引”可以被放置到集群中的任何节点上。 分片之所以重要,主要有两方面的原因:   1、允许你水平分割/扩展你的内容容量 允许你在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而提高性能/吞吐量 至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由ES管理的,对于作为用户的你来说,这些都是透明的。   2、在一个网络/云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由于任何原因消失了。这种情况下,有一个故障转移机制是非常有用并且是强烈推荐的。为此目的,ES允许你创建分片的一份或多份拷贝,这些拷贝叫做复制分片,或者直接叫复制。 复制之所以重要,主要有两方面的原因: (1)在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。 (2)扩展你的搜索量/吞吐量,因为搜索可以在所有的复制上并行运行 总之,每个索引可以被分成多个分片。一个索引也可以被复制0次(意思是没有复制)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变复制数量,但是不能改变分片的数量。   默认情况下,ES中的每个索引被分片5个主分片和1个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有5个主分片和另外5个复制分片(1个完全拷贝),这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上,也可以存放在多台主机上,这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。 3、插件HEAD elasticsearch-head是一个界面化的集群操作和管理工具 ● node:即一个 Elasticsearch 的运行实例,使用多播或单播方式发现 cluster 并加入。 ● cluster:包含一个或多个拥有相同集群名称的 node,其中包含一个master node。 ● index:类比关系型数据库里的DB,是一个逻辑命名空间。 ● alias:可以给 index 添加零个或多个alias,通过 alias 使用index 和根据index name 访问index一样,但是,alias给我们提供了一种切换index的能力,比如重建了index,取名● customer_online_v2,这时,有了alias,我要访问新 index,只需要把 alias 添加到新 index 即可,并把alias从旧的 index 删除。不用修改代码。 ● type:类比关系数据库里的Table。其中,一个index可以定义多个type,但一般使用习惯仅配一个type。 ● mapping:类比关系型数据库中的 schema 概念,mapping 定义了 index 中的 type。mapping 可以显示的定义,也可以在 document 被索引时自动生成,如果有新的 field,Elasticsearch 会自动推测出 field 的type并加到mapping中。 ● document:类比关系数据库里的一行记录(record),document 是 Elasticsearch 里的一个 JSON 对象,包括零个或多个field。 ● field:类比关系数据库里的field,每个field 都有自己的字段类型。 ● shard:是一个Lucene 实例。Elasticsearch 基于 Lucene,shard 是一个 Lucene 实例,被 Elasticsearch 自动管理。之前提到,index 是一个逻辑命名空间,shard 是具体的物理概念,建索引、查询等都是具体的shard在工作。shard 包括primary shard 和 replica shard,写数据时,先写到primary shard,然后,同步到replica shard,查询时,primary 和 replica 充当相同的作用。replica shard 可以有多份,也可以没有,replica shard的存在有两个作用,一是容灾,如果primary shard 挂了,数据也不会丢失,集群仍然能正常工作;二是提高性能,因为replica 和 primary shard 都能处理查询。另外,如上图右侧红框所示,shard数和replica数都可以设置,但是,shard 数只能在建立index 时设置,后期不能更改,但是,replica 数可以随时更改。但是,由于 Elasticsearch 很友好的封装了这部分,在使用Elasticsearch 的过程中,我们一般仅需要关注 index 即可,不需关注shard。   shard、node、cluster 在物理上构成了 Elasticsearch 集群,field、type、index 在逻辑上构成一个index的基本概念,在使用 Elasticsearch 过程中,我们一般关注到逻辑概念就好,就像我们在使用MySQL 时,我们一般就关注DB Name、Table和schema即可,而不会关注DBA维护了几个MySQL实例、master 和 slave 等怎么部署的一样。 ES中的索引原理 (1)传统的关系型数据库 二叉树查找效率是logN,同时插入新的节点不必移动全部节点,所以用树型结构存储索引,能同时兼顾插入和查询的性能。因此在这个基础上,再结合磁盘的读取特性(顺序读/随机读),传统关系型数据库采用了B-Tree/B+Tree这样的数据结构做索引 (2)ES 采用倒排索引 那么,倒排索引是个什么样子呢? 首先,来搞清楚几个概念,为此,举个例子: 假设有个user索引,它有四个字段:分别是name,gender,age,address。画出来的话,大概是下面这个样子,跟关系型数据库一样 Term(单词):一段文本经过分析器分析以后就会输出一串单词,这一个一个的就叫做Term Term Dictionary(单词字典):顾名思义,它里面维护的是Term,可以理解为Term的集合 Term Index(单词索引):为了更快的找到某个单词,我们为单词建立索引 Posting List(倒排列表):倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息,每条记录称为一个倒排项(Posting)。根据倒排列表,即可获知哪些文档包含某个单词。(PS:实际的倒排列表中并不只是存了文档ID这么简单,还有一些其它的信息,比如:词频(Term出现的次数)、偏移量(offset)等,可以想象成是Python中的元组,或者Java中的对象) (PS:如果类比现代汉语词典的话,那么Term就相当于词语,Term Dictionary相当于汉语词典本身,Term Index相当于词典的目录索引) 我们知道,每个文档都有一个ID,如果插入的时候没有指定的话,Elasticsearch会自动生成一个,因此ID字段就不多说了 上面的例子,Elasticsearch建立的索引大致如下: name字段: age字段: gender字段: address字段: Elasticsearch分别为每个字段都建立了一个倒排索引。比如,在上面“张三”、“北京市”、22 这些都是Term,而[1,3]就是Posting List。Posting list就是一个数组,存储了所有符合某个Term的文档ID。 只要知道文档ID,就能快速找到文档。可是,要怎样通过我们给定的关键词快速找到这个Term呢? 当然是建索引了,为Terms建立索引,最好的就是B-Tree索引(MySQL就是B树索引最好的例子)。 我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的 MyISAM中,索引和数据是分开,通过索引可以找到记录的地址,进而可以找到这条记录 在倒排索引中,通过Term索引可以找到Term在Term Dictionary中的位置,进而找到Posting List,有了倒排列表就可以根据ID找到文档了 (PS:可以这样理解,类比MyISAM的话,Term Index相当于索引文件,Term Dictionary相当于数据文件) (PS:其实,前面我们分了三步,我们可以把Term Index和Term Dictionary看成一步,就是找Term。因此,可以这样理解倒排索引:通过单词找到对应的倒排列表,根据倒排列表中的倒排项进而可以找到文档记录) 为了更进一步理解,用两张图来具现化这一过程: (至于里面涉及的更加高深的数据压缩技巧,以及多个field联合查询利用跳表的数据结构快速做运算来查询,这些大家有兴趣可以自己去了解)

问问小秘 2020-04-29 15:40:48 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站