IFTTT了解一下

8,983次阅读

共计 2272 个字符，预计需要花费 6 分钟才能阅读完成。

在什么都讲究「智能」的今天，互联网服务日新月异的变化可能会使你眼花缭乱。社交网络、云服务、网络媒体、电子商务，这些都无不穿插着你的生活。在现在更友好的 Open API 时代，双赢变成了多赢，一个用户每天都需要面对着多种社交媒体，他们在各种媒介上都有着不同的目的。而在后 Web 2.0 时代，人们更为渴望碎片化的网络信息得到疏导与整合，能够集中处理每天信息的组织与收发，于是，一个更被看好且具有跨时代意义的服务更好的完成了人们的夙愿——它就是 IFTTT。

IFTTT了解一下

IFTTT 是 If This Then That 的缩写，它是一个新生的网络服务平台。通俗的来讲，IFTTT 的作用就是如果触发了一件事，则执行设定好的另一件事。所谓的「事」，指的是各种应用、服务之间可以进行有趣的连锁反应。IFTTT 的宗旨是 Put the internet to work for you （让互联网为你服务）。用户可以在 IFTTT 里设定任何一个你需要的条件，当条件达到时，便会触发下一个指定好的动作。它就像是一座神奇的桥梁，能连接我们日常所用的各种网络服务。

举个例子：在你每天订阅的RSS（Feedly）里，如果你觉得一篇文章很好，你会给它加上星标（Favorite）以便下次查询或者浏览，但如果你想把每一次加过星标的文章自动存入你的 Evernote （印象笔记）里呢？使用 IFTTT ，通过简单的设定，就能很好的完成这个流程，即：RSS feed → Favorite → IFTTT → Evernote。一次设定后就会一劳永逸，当然，这只是 IFTTT 中一点微不足道的功能。

IFTTT 有几个主要的概念需要我们了解，它们是：

Channels（频道）
Triggers（触发器）
Actions（动作）
Ingredients（组成要素）
Recipes（流程）

在 IFTTT（ If This Then That ）中，this 这里所要进行的操作被称为 Trigger（触发器），也就是你在某个网络服务的操作行为；

而 that 则意味着连锁反应所带来的另外一个网络服务行为 Actions（动作）。

Triggers 与 Actions 都需要依托一定的网络服务（例如我们日常用的 Evernote、Dropbox、Github，还有主流的社交网络），这些都存在于 Channels（频道）里。

用户所要完成的整个 If This Then That 的举措则被定义为 Recipes（流程）。

其实我看到IFTTT是从咸鱼的IFTTT系统得知这个概念，闲鱼也是基于这个概念开发了一个系统，在PUSH这块拿到了不少的收益。

IFTTT了解一下

设计场景快速接入的目的是让业务对接入闲鱼IFTTT无感知，因为在最开始的设计中，场景接入是准备通过在业务逻辑里增加AOP切面，将业务数据和场景上报。但因为这种方式对业务本身有一定侵入，增加业务执行的RT而且不够灵活，最终被否决。

而现在的场景快速接入方案解决了这些问题，通过SLS接入所有应用的海量网络请求日志，记录请求的URL、参数和响应；将SLS作为Blink流计算任务的数据源；根据diamond动态下发的规则实时筛选网络请求URL和参数，把数据按照指定格式组装后上报给Channel层。

场景快速接入方案将业务逻辑与场景接入解耦，支持快速接入，灵活变更且延迟低，是针对大数据场景接入的高性能解决方案。

计算用户名单模块采用责任链模式设计，因为在不同Trigger场景中，业务对用户名单的计算和筛选逻辑都是不同的。通过责任链模式，将主流程与业务筛选逻辑解耦，并支持各业务灵活定制筛选逻辑，互不干扰。

Action层是闲鱼IFTTT中最重要的一环，会直接触达到用户，Action的逻辑会直接影响用户对平台的直观感受和活跃率。消息Push是Action中最常见的逻辑，更要防止用户被骚扰，PushAction逻辑如下：

敏感人群过滤；
疲劳度校验；
对发送人群进行AB实验；
组装消息；
将Action各节点日志同步到SLS，方便检索和排查问题；
统计消息发送数据及点击数据，为业务后续决策提供依据；

其中，疲劳度是防止用户被骚扰的关键，我们针对疲劳度进行了分层设计，分为三层，第一层为用户级别疲劳度，控制一个用户在一个周期内收到消息数量；第二层是业务维度，控制用户在一个周期内收到某个业务的消息数量；第三层是目标级别，控制用户在一个周期内收到同一个发送者消息数量。

在业务维度层面，支持灵活控制多个业务联合疲劳度，保证用户不会被消息过度骚扰。

IFTTT了解一下

用户关系数据是闲鱼IFTTT的基石，它的特点是存储量级大，达到TB级别；而且对存储和查询的性能要求高，TPS和QPS的峰值都在一万以上。经过调研，我们发现集团内部开发的Lindorm可以满足需求。

Lindorm是阿里内部基于Hbase自研的高性能KV存储数据库，对Hbase的性能和稳定性均有一定优化。闲鱼IFTTT采用Lindorm作为用户关系数据存储，经性能测试验证数据读取QPS达到7万，数据存储TPS在10万以上。Lindorm本身性能优异，为闲鱼IFTTT高性能奠定基础。

https://mp.weixin.qq.com/s?__biz=MzU4MDUxOTI5NA&mid=2247484550&idx=1&sn=f3b0c6760781966a0687ba3eb2a0b167&scene=21#wechat_redirect#
https://sspai.com/post/25270

‍

正文完

请博主喝杯咖啡吧！