浅谈微服务注册中心与分布式锁

问题的引出：

前几天面试了一个童鞋，他说熟练掌握分布式开发，微服务设计实现，然后我就简单问了几个问题，感觉聊得还挺愉快的，这里记录一下相关的知识点

1.简单对比了注册中心ZooKeeper与MySQL

>dubbo框架注册中心使用ZooKeeper可以替换为MySQL吗？

不可以，MySQL是数据库<

>注册中心注册的是什么东东？

微服务启动时生产者向注册中心节点写入信息，消费者去注册中心取对应数据。<

>写入的信息是什么东东，消费者取到的又是什么东东？

 额，不太清楚。<

>咱的微服务不就是个RPC调用吗，写入的是服务的URL地址啊，这和咱请求一个URL不是一样的吗，知道了地址不就可以访问了吗？

对对对，刚才有点短路，是URL地址，RPC调用。<

>那竟然是数据，MySQL也可以保存啊，注册中心换成MySQL没问题吧？

额，但是微服务都是分布式的，都是不同的数据库  <

>那我的分布式服务就共用一个MySQL，这没问题了吧，我建个表，把URL地址写到数据库表里，从表里查数据？

恩，您这么一说确实没问题，但是感觉怪怪的，您帮我捋一捋吧<

>咱就举一个最简单的例子，zkClient断开时会自动删除临时节点信息，这样某个生产者挂掉时，URL地址就移除了，MySQL可以自动删除废弃的URL吗？

哦，明白了，多谢了。<

2.简答谈了一下为什么要用Redis

>为什么要使用redis呢？

缓存，加快访问速度<

>缓存放到本地不是更快吗，redis还得请求一次

恩，本地内存资源宝贵，

我们的图片都是另外启的图片服务器<

>如果本地内存无限大，那就不需要redis了吧

    额，无限大的内存，好像是不需要redis，直接本地缓存<

>那你觉得用redis还带来哪些好处？

恩，redis作为中间件，当然还起着解耦的用，多个系统可以通过redis交换数据；同时redis还可以用来集中式管理，比如session会话管理。<

>恩，说的不错，看来这次没有短路。

3.简单设计一个分布式锁。

>现在我的分布式系统中有一个公共资源，各个系统访问公共资源数据时，我需要上一把锁，你如何design？

这个我只需要保证在分布式访问中，每次仅有一个服务操作公共资源即可，可以利用中间件技术吗<

>当然可以，给出你的思路就好。

mq就可以，我把一个个请求顺序放到一个队列里，然后一个消费者一次取一条慢慢处理<

>恩，可以的，既然说到mq，那mq还带来哪些好处

mq同样作为中间件，可以解耦合，提供了异步处  理机制，能够起到缓冲的作用<

>如何起到异步处理机制，有用到的案例吗？

有的，我们的微信公众号后台开发，有的消息处理需要调用各个系统拉取账单数据，而5秒内没有响应微信就会断开连接，所以我们收到用户消息后，立即返回，然后消息  入队列，再调用微信客服接口，将消息推送给用户<

>恩，不错，假如让你使用ZooKeeper实现下分布式锁，如何设计？还是思路即可

zk的话借助临时节点，递增的序号，watch监听事件， 应该也可以，让我整理一下思路<

>恩，我能get到你的点，你整理下

还是以保持顺序性为前提，然后分布式服务连接zk，获取同一个父节点下的所有节点序列号，然后每个节点监听它之前的节点，只要之前的节点处理完删除节点后，就轮到  自己处理了，否则等待前一个节点，大概这样吧<

>恩，思路有了，实现起来把握住几个点就OK。