架构实践(转)

1. 从0开始做互联网推荐-以58转转为例

    1)从0开始设计推荐产品框架

        (1)首页推荐:提取用户画像,根据线下提取出的用户年龄、性别、品类偏好等在首页综合推荐宝贝

        (2)宝贝详情页推荐:买了还买,看了还看类的关联宝贝推荐

        (3)附近推荐:和首页推荐的差异在于,提高了地理位置的权重,地理位置不仅要包含当前地理位置,还需要包含常见活跃区域,例如家里、公司等

        (4)搜索推荐:除了关键词全匹配,要考虑同义词、近义词、易错词、拼音等推荐,产品层面,提示“你是不是想找xxoo宝贝”

        (5)召回推荐:在用户退出系统后,通过RFM模型做优惠券推送或者消息推送做客户挽留与召回

         TIPS:什么是RFM模型?

         RFM模型:根据用户最近一次购买时间Recency,最近一段时间的购买频度Frequency,最近一段时间的购买金额Monetary,加权得到的一个代表用户成交意愿的一个分值。

   2)从0开始进行推荐策略实现

         a. 用户画像

         b. 如何构建画像

             a). 读取用户安装的应用程序列表构建画像

             b). 用户行为日志

         c. 宝贝画像

         d. 如何构建宝贝画像: 对于58转转来说,要做宝贝画像必须细分类别,可以分词词频统计配合人工review的方式画像

         e. 标签化与个性化推荐

         f. 分类预测推荐

         g. 协同过滤推荐

2. 58到家入驻微信钱包的技术优化 

    “页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术,总数据量不大,生成静态页面数量不多的业务,非常适合于“页面静态化”优化

    文章转自:https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959423&idx=1&sn=19d27145beab5b0238280e2e3804e41b&scene=21#wechat_redirect

   

3. 创业公司快速搭建立体化监控之路(WOT2016)

    创业型公司快速实施立体化多维度监控总结:

   (1)机器、操作系统维度监控:zabbix

   (2)进程、端口维度监控:分发型监控 + 汇总型监控

   (3)错误日志与关键字维度监控

   (4)keepalive接口与所有接口统一处理时间统一上报监控

   (5)模拟调用方调用站点、服务,来对站点和服务进行监控

     转自:https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959433&idx=1&sn=9c9a222c06b2426f3935b04a10f90c0b&scene=21#wechat_redirect

4. 怎么判断哪个执行成功,哪个执行失败

    set操作,其实无所谓成功或者失败,业务能通过affect rows得知哪个修改没有成功:

    执行成功的业务,affect rows为1

    执行失败的业务,affect rows为0

5. 百度咋做长文本去重(一分钟系列)

    文本相似性的签名算法: 

    可以用局部敏感哈希LSH(Locality Sensitive Hash)解决,局部敏感哈希是一类文本越相似,哈希值越相似的hash算法,有兴趣的同学自行百度,这里分享一下minHash的思路。

    问题的提出:什么是minHash?

    回答:minHash是局部敏感哈希的一种,它常用来快速判定集合的相似性,也常用于检测网页的重复性,其思路为,用相同的规则抽取集合中的少部分元素代表整个集合,如果少部分元素的重合度很高,非常可能整个集合的重复度也很高。

6. 如何快速实现高并发短文检索

    推荐:

    核心思想就是“内存hash + ID list”

    索引初始化步骤为:对所有标题进行分词,以词的hash为key,doc_id的集合为value

    查询的步骤为:对查询词进行分词,对分词进行hash,直接查询hash表格,获取doc_id的list,然后多个词进行合并

    这个方法有什么优点呢?

    龙哥:存内存操作,能满足很大的并发,时延也很低,占用内存也不大,实现非常简单快速

    问8:有什么不足呢?和传统搜索有什么区别咧?

    龙哥:这是一个快速过度方案,因为索引本身没有落地,还是需要在数据库中存储固化的标题数据,如果不做高可用,数据恢复起来会比较慢。当然做高可用也是很容易的,建立两份一样的hash索引即可。

    另外,没有做水平切分,但数据量非常非常非常大时,还是要做水平切分改进的。

7. 如何实现超高并发的无锁缓存?

    在【超高并发】,【写多读少】,【定长value】的【业务缓存】场景下:

    1)可以通过水平拆分来降低锁冲突

    2)可以通过Map转Array的方式来最小化锁冲突,一条记录一个锁

    3)可以把锁去掉,最大化并发,但带来的数据完整性的破坏

    4)可以通过签名的方式保证数据的完整性,实现无锁缓存。(根据签名验证数据是否正确,如果错误则说明数据已经被修改)

    内容转自:https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959502&idx=1&sn=7a1c7d81a8e030856fb920844dc571c6&scene=21#wechat_redirect

 

8. 从IDC到云端架构迁移之路(GITC2016)   

    (1)互联网单机房架构的特点,全连,站点层全连业务服务层,业务服务层全连的基础服务层,基础服务层全连数据库和缓存;

    (2)多机房架构的特点,同连,接入层同连服务层,服务层同连缓存和数据库,架构设计上最大程度的减少跨机房的调用;

    (3)自顶向下的机房迁移方案:先进行站点接入层、业务服务层和基础服务层的迁移,搭建服务,逐步的迁移流量;然后是缓存迁移,搭建缓存,运维修改缓存的内网DNS指向,断开旧连接,重连新缓存,

             完成迁移;最后数据库的迁移,搭建数据库,数据进行同步,只读,保证数据同步完成之后,修改配置,重启,完成迁移。整个过程分批迁移,一个业务线一个业务线的迁移,一块缓存一块缓存的迁移,

             一个数据库一个数据库的迁移,任何步骤出现问题是可以回滚的,整个过程不停服务。

原文地址:https://www.cnblogs.com/Jtianlin/p/8971745.html