System Design [youtube搬运] Tinder 笔记

System Design: Tinder as a microservice architecture

原视频链接

https://www.youtube.com/watch?v=tndzLznxq40

面试的时候系统分析最好从客户的需求开始分析，用户需要什么样的功能（feature），然后再拆分具体的功能，再考虑用什么样的方式来实现具体的功能。

Tinder Architecture，也就是Tinder 需要满足用户的功能包括

1) store profile ， 存储用户信息 (images)

2) Note matched，记录用户匹配 (假设 0.001*number of active user)

3) Direct messaging，用户之间互相传信息 

4) recommend matches，向用户推荐匹配的人 (number of  active users)

 

1) store profile

首先需要考虑的问题是以什么样的方式来存储profile 数据。

这个功能比较关键的一点是需要存储很多的profile图片，图片的存储是很有争议的。争议主要集中于图片存储方式应该是哪种。

File vs. BLOB (Binary large object， 一个数据库的概念)

数据库能提供的性能包括 1）Mutabiliy, 2) Transaction guarantees (ACID), 3）Indexes （improve search cabability），4）access control

首先讨论Mutability，主要考虑图片会不会被修改，图片一般修改会是一个新的图片，所以图片是immutable的，这个mutability的性质就不需要。

再者，transcation主要保证的是图片修改的原子性（automicity），对于这个情景来说也是不需要的。

同样，Indexes 也不需要。

但access control还是很重要的。但是file system 也能提供access control。

 

所以综上，在tinder里更适合存储图片的方式是使用file system。 因为file system更a) cheaper，b) faster （在数据库中可以做object partitioning，但是如果对于所有的img file 运行select * 命令，就会比file system 慢的多），c) content delievery network (可以使用distributed file system, aka. dfs 来使访问更快)。

但如果面试官坚持使用BLOB，也不是不可以。

 

再者需要考虑如何实现profile相关的功能。

   当用户建立了自己的profile后想要更新自己的profile就需要向profile service（可以考虑为一个server，这个server还连着存有profile 信息的数据库）发送update的请求，这个update的需要通过一定的机制来完成身份得验证（authentication），保证修改profile的人就是创建profile的人。一种方式是可以通过在update请求使用user name和password，这样的传输password也不太安全，所以另一种方式是使用username和token来作为身份验证。

  使用token的一个问题是，如果之后有新的sevice需要用户的username和token来进行身份验证，此时这个新的service上没有这些在profile service 上的信息，那么这个新的service就需要向profile service 来获取username和token。如果有更多新的service，那么这些新的service都需要向profile service 请求username和token，这样每个新的service上就会有很多重复的逻辑代码。

  一个解决这个问题的办法是使用gateway，这样用户（手机APP）就不能和任何的service直接传输信息。每次gateway来负责向profile service 确认username，tokens之类身份验证信息是否正确，正确的话再由gateway转发用户的请求到对应的service，gateway再转发service的response给用户。

  这个操作是decouple（去耦合）system。把和用户通信的功能单独放在了gateway service 上，而不是允许各个service都与用户交互，这样对后面不同的messaging protocol 非常有好处。

  profile service 的数据库中应该存储一些description，name之类的信息。对于图片是否也要存储在profile system这一点很难有绝对的对和不对。逻辑上讲应该将图片的存储放在新的service上，这样如果需要集中对图片进行一些分析，进行一些机器学习的算法，更好的选择是用单独的image service，这个image service连接的了dfs，以及一个数据库（存着profile id，image id, file url in dfs）。这样在只需要description和name之类比较轻量级的信息时，profile service 能比较快的处理，处理image这种比较重量级的信息时可以用image service 单独来处理。

 

2）direct messaging

  用户a需要和用户b进行通信，用户a需要先发message(user1, user2)的请求给gateway，gateway再转发给用户b，通过XMPP协议，TCP连接。

  在用户和用户需要频繁聊天交互的情况下，采用client-server protocol 是不太有效的，因为这样用户需要每隔一段时间去问server有没有我的新的message。这时需要采用peer to peer protocol。client-server的protocol 有http之类的。peer to peer protocol可以用到当前情况的是XMPP。

  每个用户和gateway建立的连接都有一个connection ID，将这个保存查询userID对应的connection ID，可以通过将这个功能从gateway中分离出来来decouple system，分离出来的新的service就是session service。在这个service上就有数据库存有connection ID和对应的userID的数据表。

 

3）noting recommendation

  可以选择在用户APP所在的设备上存储用户的匹配记录，也可以选择在服务器端用一个单独的service，matching service 来存储所有用户有过的匹配记录，比如说一个数据表上存有（userID1, userID2）代表用户之间是否存在match。

  存在server上的一个好处是如果用户的设备crash了，或者本地记录被删除了，那么service 端还有备份能重新恢复。用server存储当两个用户要进行通信的时候，就需要先经过gateway，再到match service看两个人是否匹配，再经过session service，看对方用户是否和gateway建立了连接，connection ID是多少。如果本地记录都删除的话不能从service 端恢复的是你向右或向左滑了谁，但从match service 恢复你已经和谁进行了匹配，这样存在的问题是可能会存在重复推荐，但不是个太大的问题。

 

4）recommendation

  在profile service 上会存有一张数据表，其包含的内容有user的age，user的gender, location。一张数据表不能在同一时间对age，gender，location等多个field进行操作，每次建立的Index只能处理以某一个field为主的过滤条件。query执行的效率很大程度上取决于database optimizer和query optimizer。

  在这种情况下可以考虑使用nosql database Cassandra，Cassandra能够多次复制数据，根据query建立不同的数据表。

总的来说存储用户的profile

1) 对于no sql database可以考虑使用。分布式的数据库比如Cassandra / Amazon Dynamo

2) 对于不熟悉distributed database的人，可以考虑使用relational database，关系型数据库，采用sharding的技术，这个技术也叫horizontal partitioning。举例来说，可以将某个field比如说age，取指定数据范围的数据放在指定的服务器上。对于name(A-J)->server node 36，对于name(K-P)->sever node 79。

那么如果某个node fail怎么办呢？可以采用master- slave结构。

  整个app的recommendation engine 不需要特别的复杂，可以decouple出来一个recommendation service，这个service 可以简单地存储用户和他们的location，每隔几个小时可以更新一下location，通过简单的filter来实现推荐。