高德:Redis深度实践,助力实现“现实与互联网世界的底图梦”

  • 时间:
  • 浏览:0
  • 来源:5分11选5_5分3D

作为互联网世界底图,目前10部手机中完整性总要9部在使用高德的位置服务,简单介绍下另4个 行业的案例:高德开放平台为国内85%的车行App提供地图、导航和路径规划服务;为市场中超过50%的外卖App提供地图和定位服务;为50%的主流社交应用提供精准位置和搜索功能,如发微博时的地点定位。目前,离米 有50万款应用正在使用高德开放平台业务。

高德主营地图业务,会有后会 数据更新的场景,比如今天通过数据挖掘发现有一家加油站不营业,那为什发现呢。就是说后会在9点钟的后会,用户的定位点这里会有50辆车,今天发现不都可不可以 一百公里或都太难 了,原本 持续了一定时间后,就知道出问提了,再去查证,好多好多 就会有数据的更新。最土的措施 就是不把一批量的数据更新,而以A/B集群的措施 更新,原本 不能外理好多好多 写入后会的延迟对整个性能的影响问提。这时写入是另4个 持续的操作,当写入完成的之总要有另4个 校验的流程,当一切确认的后会,会切换进去(这里有另4个 冷集群和另4个 热集群)。这是地图行业比较讨巧的另4个 做法,在纯线上业务可能不太会太难 做,但在后会 集中性的数据发布时就比较常见。



接下来到高德真正利用到Redis原生机制做双机房同步的后会了:为了缓存同步的一致性,将数据化打开,采用持久化去做同步。但实际在你你这俩 情況下,有另4个 机制判断当前谁是主、谁是从、哪里是写入点,把它写入到对应的Master底下,后会 后会 节点会依照Redis把它拷贝过去。





计费集群也是Redis的上层应用。在跨机房之间有ZK的全职,底下的Redis互相不同步,不都可不可以 本机房的信息,计费集群跨机房择主,太难 你你这俩 多多进程 就会向被选为主的集群写入信息来归总这份数据,底下可能涉及到无法选则或无法连接的情況,(可能是Snapshot场景)它会等待图片可用。就是说你规定了15秒的快照时间,有可能可能推迟会变成50秒或40秒,太难 在计费集群的HBase下面会有另4个 Open TSDB做真正的存储。上层的Redis会保留一段时间,可能出现后会 计算错误或用户投诉,就反查回来看一下是完整性总要有问提,但本质上是以最终落地的那份数据为主。但你你这俩 例子完整性总要实时,计费报表并完整性总要马上出,可能第三三5天 或过三三5天 才出。好多好多 这里在业务上做了后会 选则,会把实时牺牲掉来保证正确性或性能。

目前用户使用的高德地图,人太好是C端地图,另外还有另4个 出口:另4个 是车机地图;另外另4个 是开放平台。开放平台就是行业合作,比如说使用打车应用或社交应用会请求高德的API,简单地说,就是SDK和API的业务。

顺便提一下分片混合部署,现在高德后会有较大的抖动,数据自动地分布到不同的机房和节点,不能保证另4个 小分片同总要有另4个 副本,且找不到同另4个 机器上。这也使得数据向下切割成另4个 分片时保证存储可靠,后会 它始终会有另4个 Primary的主写入节点。

在跨城的场景下,以计费为例。计费是流量的统计,就是说另4个 开放平台,发流量配额给后会 合作伙伴,我应该 一分钟50万的配额,那你的请求实际上是落到全国各地阿里云的机房,那怎么可不可以快速有效地统计哪几个流量,在超量的后会及时告诉你呢?



第二种也很简单:在业务层面做后会 选则。之类另4个 机房,并希望读取的次数高时,不能做另4个 双写。这完整性总要另4个 正统和学术的措施 ,它会原因分析一致性的问提:可能双写时本机房的写好了但超时了,这时就我就是知道写没写进去。

以下内容根据演讲PPT及现场分享采集。

这其中除了涉及到数据搬迁,还有最上层的流量分配(怎么可不可以保证把用户采集到正确的地方去)。高大上的答案是不能通过地域化的DNS,但总要有百分之几比例的用户会发错,你你这俩 情況下就通过7层把流量转发过去,此总要有50毫秒的IT开销甚至数以倍计的可靠性的下降,这就是另4个 短暂的措施 ,将来会通过Channel的建设,DNS的解析等尽量去提高采集的比例,这也是高德正在做的另4个 事情。

这是另4个 核心问提,人太好是另4个 跨机房汇总问提。也就是说,可能每个流量收一毛钱,那用户设置的后会,我只我应该 50万流量,超过就停掉,那跨机房统计费用的及时性就直接原因分析了控制与非 准确。但可能可能数据的不同步,在外地多跑了5万,那这5万就收不能 钱。本质上这是另4个 时效性问提,可能接入点在多个机房,后会 机房距离比较远,那为什保证时效的正确性?基本做法是在所有机房的接入层把所有流量原封不动地写入到缓存集群;后会 缓存集群会分带宽做出另4个 Snapshot,带宽随着业务压力大小而变化,并直接影响到计费统计的反应能力。原本 超量就会发现,带宽会保证流量及时地记录下来。记下来之总要通过阶段性的Snapshot,专门有另4个 多多进程 往计费集群中写。

高德经典数据库应用场景

Cache场景主要偏向机房和机房之间整个应用的部署。当业务做到一定规模的后会,可靠性就太难做到,需用依赖好多好多 环境。之类阿里云的后会 技术在下层会有好多好多 链路、机房、甚至说后会 技术提供商的劫持问提,在做服务时,也相应地诞生非常多的可能。

现在描述数据更新业务的后会,实际上在更新之总要有另4个 ZK的机制做切换,业务会自动地通过信息知道现在占据 哪个集群。当新集群上线后会,旧集群会等待图片下一次数据更新。

谈到同步,上图人太好是Albiter的图,但在Redis里也相同。当在同城之间需用判断主和从与非 要需用提升时,人太好不能 依赖另4个 节点的判断来做。这是可能:一是两者之间太难 措施 判断谁是活的、谁是死的,其他同学都人太好后会 人是活的;还有另4个 原因分析是网络抖动很有可能在很短的时间占据 并在很短的时间内恢复,比如说抖动了5秒或6秒,这时对持久化数据库的简单主从的提升操作会加剧数据的不一致,好多好多 会引入第另4个 机房来帮助判断。



下面来看一下机房之间的Redis应用。

下面你你这俩 步好多好多 人总要遇到,当数据热了要重新分布就会有Proxy的改造方案,离米 把数据的分布策略和动态的重新平衡策略做进DB,不再拿给业务做。这是可能当不都可不可以 另4个 主流业务,不能全身心关注;后会 可能有20个业务,每天完整性总要不同的出问提,这完整性总要了Proxy的方案,希望把整个发现好多好多 放入Redis底下,业务不须Care。典型的逻辑是把服务的发现和Hash好多好多 放入另4个 Proxy层底下,后会 通过另4个 额外配置的底下管理去Client,使其知道应该读哪个Proxy。



高德的经典数据库应用场景底下怎么可不可以同时为C端和B端用户提供全量服务的呢?实际上两者模式完整性不一样,C端有高峰,对于高德,可能十一的第一天就是C端的高峰;对于微博来讲,女排夺冠那天可能就是高峰;但B端很坑,它的高峰每天完整性总要,50万个应用每天完整性总要后会 人的业务高峰,它们个人的高峰就是B端的高峰。

上图左下角表达的是业务监控系统监控机房,当压力比较大总要有后会 抖动,这需用判断需不需用响应。目前,架构中占据 两套业务监控系统:一套是性能层面;一套是语义层面。即有另4个 监测内存、CPU等;有另4个 负责业务。

未来,高德会同阿里云一道设计就近接入的方案,该业务和地理位置高度相关,把用户数据放入离他比较近的地方。人太好就是把用户的数据按照对应纬度或所属地区的纬度切分到对应的机房去,用干预的措施 尽量选到所属的主节点,在主节点找不到问提的情況下,希望用户的数据从哪里写就从哪里读。后会 机房会作为他异步传输的同步。



最后简单分享一下真正的挑战,后会讲的好多好多 场景完整性总要选则。读完马上就要写的业务,你你这俩 场景最难。

后会 Cache场景不能简单粗暴的外理后会 问提,尽可能拿到98%、99%的收益。采用你你这俩 措施 的好处是:读和写非常稳定。这里需用注意的是同城之间,可能同城之间的风险就是在双写的那一刻,完整性总要写失败的问提,就是我就是知道有太难 写成功。同城双机房缓存双写的情況是只读后会 人的,放弃写入到A或B,它会像当前逻辑上的Master去做写入,好多好多 你你这俩 后会是跨机房的。

先从最简单的同城双机房随后开使。当业务达到一定程度时,需用部署双机房,通常会选在同另4个 城市,将应用成本降到最低。将其中另4个 机房当做Cache用,通常是把它直接落到另4个 地方,这就离米 有另4个 机房,后会 Redis只在另4个 机房里。这是最简单的,也是业务方面极为常见的另4个 场景。在做另4个 新业务的时,不能先用你你这俩 措施 过渡,当业务量不大时,这是最快的本身措施 。你你这俩 点也说明了服务化还有很长的路要走;可能服务化做得好,会直接达到非常完美的情況。

高德在Codis方面起步较晚。目前,高德所有的主流业务完整性总要自家的平台上;还有后会 业务依赖Redis。利用Codis部署将上层流量分下来,再通过业务化Hash将其分到不同的分组去,也可能是同城另4个 机房的某个地方;图中的ZK既用作Master接入点的发现,也用来做分组信息的维护。在此类场景中,另4个 实例上或多个实例上会有不同的GROUP,通过分组信息,找到你你这俩 GROUP,再把数据写进去可能读出来,整体的读取或写入流量是由上层通过业务负载进行转发。



Codis集群部署

在2016杭州云栖大会的“开源数据库之Redis专场”上,高德开放平台总经理童遥带来了题为《高德经典数据库实践案例分享》精彩演讲。演讲中,他主要介绍了高德业务下的经典数据库实践案例。





Cache场景

异地单元化&就近接入



持久化场景