架构师之路--搜索业务和技术介绍及容错机制

 今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术。发现现在90后小伙都挺不错。我是指能力和探究心。我家男孩,不招女婿。

  在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级。我们UV,PV,CV,VV都是保密的。所以作为一个合格的员工来说………………数值我也不知道。总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里。大体流程图如下:

  这个流程图之所以没像以往一样手绘,嗯,那是因为:钢笔放在公司了。

  这里面除了两个库都在我们这边之外,其他的一个框是一个部门。我们这边给pipeline的数据交付使用的是我开发的离线服务。pipeline将各个来源的数据做重复归并处理。就是一些视频内容是一样的,但是可能来源不同或者名称有相似但可能不完全相同,而实际上是一个视频。打个比方,大学时看过一个电影叫<a Cinderella story>翻译成中文有的翻译成《灰姑娘的故事》也有翻译成《灰姑娘的玻璃手机》,但是可以根据其导演和演员表等判断其实是同一个视频。这些相同的视频要聚合成一个专辑。推举最优质的描述作为专辑的描述。展开详情有各个来源的排序后视频列表。

  正常全网搜索也会将自家的视频放在前面:

  这个归并处理大家可能也猜到了,并行计算嘛,用的是mapreduce。因为是视频数的组合操作,数量级是蛮大的。搜索引擎返回的是数据都是ID,真正的数据从详情部门返回。加个代理是啥意思?对调用端透明嘛,有修改只要改代理端。

  搜索引擎是独立的部门,没打过交道。但是我在上家公司的公司主要负责全公司的垂直搜索,数据来源都是关系型数据库,数据量不大,当时用的是搜索引擎用的是solr。分词器用的是开源的IK分词器。因为当时公司做的是面向企业家的高端人脉,搜索对人名,公司名等的检索结果的排序有很多特殊的要求,所以当时研究过分词器的源码,也对分词器进行了一些更加切合项目的改造。比如有个需求是过滤输入的html标签。但是在Solr中对索引读入后的第一个操作就是分词,使用Solr自带的或者外部的分词器。然后再对分好的词进行更细节的过滤或者近义词之类的。但是这第一步就直接破坏了文档的结构,变成了一个个单词,而不是html文档形式。再去除很麻烦而且效率低。所以我当时的做法是直接修改了IK分词器的源码,读入数据第一个操作先过滤标签。apache有现成的工具类。这样避免了读入读出带来的性能损耗。当时也做过测试,循环跑10w次用我改造后的分词器和不改造分词器用solr过滤器过滤正则表达式的方式比的话,执行效率大约高出20倍。当时的还发现不管是solr还是ES,都是基于lucene的嘛,更适用于西文的一些检索。像中文检索不需要像西文那样需要语言处理器变小写然后再基于算法或匹配进行词根化。反而需要更多基于词典的,包括同义词,近义词这些。所以从分词这方面也是有很多的优化空间的。

  个人觉得做搜索数据分析很重要。比如从日志分析中可以发现有些用户输入搜索关键词:贾跃亭,那么他很有可能对包含“乐视”关键词的信息也很有兴趣。发现了这个问题之后,我就对这类数据做了一个词库,进行了搜索和索引上一些词的双向绑定。就是相当于一个同义词的功能。建议将本文的题目放到几个搜索引擎里搜索一下,对比看看结果,挺有意思。

   详情数据也是存在文档型数据库里,其实用mongoDB挺合适的。但是公司有统一的cbase集群,就直接放到cbase里了。我经常需要跟人家解释半天:cbase,couchbase,memcached都是啥关系。memcached大家都很熟悉。但是memcached不支持持久化。如果使用单纯的memcached集群,节点失效时没有任何的容错。应对措施需要交由用户处理。所以就产生了一个加强版的memcached集群:couchbase。数据层以memcached API对数据进行交互,系统在memcached程序中嵌入持久化引擎代码对数据进行缓存,复制,持久化等操作,异步队列的形式将数据同步到CouchDB中。由于它实现了数据自动在多个节点本分,单节点失效不影响业务。支持自动分片,很容易在线维护集群。cbase又是啥东西呢?这是我司对couchbase进行了一个二次开发,主要的改进点是对value的最大值进行了强行扩容:本来memcached最大Value设定是1M。我们给扩容到4M。但是慎用大的value。value值从1K到不超过1M平均分布时,实际使用容量不超过50%时性能较好。如果大value很多,达不到这个值性能就会急剧下降。

  早在08年,09年的时候。facebook,mixi等国外知名互联网公司为了减少数据库访问次数,提高动态网页的访问速度,提高可扩展性,开始使用memcached。作为以facebook为标杆的人人网,这种技术也很快在其内部各个部门得到了普及。因为memcached集群采用的是服务器间互不通信的分布式方式。客户端和服务器端的通信采用的是分布式算法。这就是所说的节点失效时没有任何的容错。

  这里提一个概念,就是常见的容错机制。我知道的,主要是6种。

  ☆ failover:失败自动切换

    当出现失败,重试其他服务器,通常用于读操作,重试会带来更长延迟。

    像我们的MQ客户端配置,采用是failover为roundrobin。采用轮询调度算法来容错。

  ☆ failfast:快速失败

    只发起一次调用,失败立即报错,通常用于非幂等性的写操作。如果有机器正在重启,可能会出现调用失败。

    我们的一个数据库虽然升级成了mariaDB。但是还是一主多从。这时候写入主库失败采用的就是failfast方式。

  ☆ failsafe:失败安全

    出现异常时,直接忽略,通常用于写入日志等操作。

  ☆ failback:失败自动恢复

    后台记录失败请求,定时重发。通常用于消息通知操作。不可靠,重启丢失。

  ☆ forking:并行调用多个服务器

    只要一个成功即返回,通常用于实时性要求较高的读操作。需要浪费更多服务资源。

  ☆ broadcast

    广播调用,所有提供逐个调用,任意一台报错则报错。通常用于更新提供方本地状态,速度慢,任意一台报错则报错。

  读过《java并发编程实践》的朋友看到容错机制很容易会联想到java的fail-fast和fail-safe。周五和90后小伙子交流技术也正好聊到集合类的相关问题。有一个问题是在AbstractList的迭代器中,set操作做了expectedModCount = modCount。按理说不需要改变长度,为啥也要做这个操作。而实现它的子类set中都没有实现这个操作。我的想法是有一些实现set的方法有可能是通过添加删除来变相实现的。总之,继续于这个AbstractList的实现类都会检查这个expectedModCount 和 modCount的一致性。不一样会即可抛出并发修改异常,这就是failfast。而像CopyOnWriteArrayList这种的,写操作是在复制的集合上进行修改,不会抛出并发修改异常是failsafe的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

最新后端架构师技术图谱!附学习资料~

版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。

1041
来自专栏Albert陈凯

2018-05-17 架构师技能图谱,搞懂这些找工作无敌数据结构常用算法并发操作系统设计模式运维 & 统计 & 技术支持中间件网络数据库搜索引擎性能大数据安全常用开源框架分布式设计设计思想 & 开发模

1972
来自专栏Java呓语

享元模式(分离与共享细粒度对象)

目录: 1、由 HTTP 协议 联想到 对享元模式的思考 2、引入礼盒问题,作为享元模式的逆向思考 3、享元模式的实现 4、享元模式总结 5、感谢帮助...

642
来自专栏Java技术栈

最新后端架构师技术图谱!附学习资料~

2082
来自专栏Java技术栈

Java 9 被无情抛弃,Java 8 直接升级到 Java 10!!

1643
来自专栏鸿的学习笔记

简单聊聊分布式系统的一致性问题

记得有人说过,分布式系统的所有问题归根结底都是一致性问题。前面文章提到的数据复制,分区以及事务面临的问题都是如何保证数据一致。而分布式系统不同于单机,它不...

611
来自专栏微信公众号:Java团长

不可多得的后端架构师技术图谱!内附参考资料!

由于知识点众多,特整理在GitHub上,微信外链限制,无法在文本中直接加上超链接,有需要的欢迎Start/Fork,地址如下:

1012
来自专栏Python攻城狮

Ajax-数据异步交互1.Ajax简介2.AJAX 实例

AJAX = 异步 JavaScript 和 XML。 AJAX 是一种用于创建快速动态网页的技术。 通过在后台与服务器进行少量数据交换,AJAX 可以使网...

913
来自专栏技术分享

.NET应用架构设计—表模块模式与事务脚本模式的代码编写

要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意,而不是胡子眉毛一把抓。现在有一个现象是什么呢,项目的结构从表面上看是很不错,层分的很合理,其实对业务...

660
来自专栏智能计算时代

区块链超级记帐本架构概览

介绍 作者:Elli Androulaki,Christian Cachin,Konstantinos Christidis,Chet Murthy,Binh ...

2594

扫码关注云+社区