下载频道  >  hyy80688的资源
  • 多点登录和消息漫游设计实现

    “多点登录”是指多个端同时登录一个帐号,同时收发消息,关键点是: (1) 需要在服务端存储同一个用户多个端的状态与登陆点; (2) 发出消息时,要对发送方的多端与接收端的多端,都进行消息投递; “消息漫游”是指一个用户在任何端,都可以拉取到历史消息,关键点是: (1) 所有消息存储在云端; (2) 每个端本地存储last_msg_id,在登录时可以到云端同步历史消息; (3) 云端存储所有消息成本较高,一般会对历史消息时间(或者条数)进行限制;

    2019-02-27
    50
  • Google BigTable

    BigTable是一个稀疏的、分布式的、持久化的、多维度排序的、大数据量存储系统,它能够解决符合上述map数据模型业务的存储问题。

    2019-02-27
    9
  • 离线消息设计实现

    “离线消息”的玩法,可能比大家想象的要复杂,常见的优化有: (1) 对于同一个用户B,一次性拉取所有用户发给ta的离线消息,再在客户端本地进行发送方分析,相比按照发送方一个个进行消息拉取,能大大减少服务器交互次数; (2) 按需拉取,是无线端的常见优化; (3) 分页拉取,是一个请求次数与包大小的折衷; (4) 应用层的ACK,应用层的去重,才能保证离线消息的不丢不重; (5) 下一页的拉取,同时作为上一页的ACK,能够极大减少与服务器的交互次数;

    2019-02-27
    50
  • 消息顺序性设计实现

    (1)要“有序”,先得有衡量“有序”的标尺,可以是客户端标尺,可以是服务端标尺; (2)大部分业务能够接受大范围趋势有序,小范围误差;绝对有序的业务,可以借助服务器绝对时序的能力; (3)单点序列化,是一种常见的保证多机时序统一的方法,典型场景有db主从一致,gfs多文件一致; (4)单对单聊天,只需保证发出的时序与接收的时序一致,可以利用客户端seq; (5)群聊,只需保证所有接收方消息时序一致,需要利用服务端seq,方法有两种,一种单点绝对时序,另一种id串行化;

    2019-02-27
    10
  • 领域模型和微服务的关系

    微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念,也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务间的相互调用和分布式事务中,这种情况微服务带来的不是便利而是麻烦。 DDD给我们带来了合理的划分手段,但是DDD的概念众多,晦涩难以理解,如何抓住重点,合理的运用到微服务架构中呢? 我认为如下的几个架构思想是重中之重 • 充血模型 • 事件驱动

    2019-02-27
    49
  • 群消息设计实现

    群消息还是非常有意思的,做个简单总结: (1)不管是群在线消息,还是群离线消息,应用层的ACK是可达性的保障; (2)群消息只存一份,不用为每个用户存储离线群msg_id,只需存储一个最近ack的群消息id/time; (3)为了减少消息风暴,可以批量ACK; (4)如果收到重复消息,需要msg_id去重,让用户无感知; (5)离线消息过多,可以分页拉取(按需拉取)优化;

    2019-02-27
    12
  • 微服务架构服务拆分粒度

    总的来说,细粒度拆分的优点有: • 服务都能够独立部署 • 扩容和缩容方便,有利于提高资源利用率 • 拆得越细,耦合相对会减小 • 拆得越细,容错相对会更好,一个服务出问题不影响其他服务 • 扩展性更好 细粒度拆分的不足也很明显: • 拆得越细,系统越复杂 • 系统之间的依赖关系也更复杂 • 运维复杂度提升 • 监控更加复杂 • 出问题时定位问题更难

    2019-02-27
    50
  • 微服务架构,RPC细节

    什么是RPC调用? 像调用本地函数一样,调用一个远端服务。 为什么需要RPC框架? RPC框架用于屏蔽RPC调用过程中的序列化,网络传输等技术细节。让调用方只专注于调用,服务方只专注于实现调用。 什么是序列化?为什么需要序列化? 把对象转化为连续二进制流的过程,叫做序列化。磁盘存储,缓存存储,网络传输只能操作于二进制流,所以必须序列化。 同步RPC-client的核心组件是什么? 同步RPC-client的核心组件是序列化组件、连接池组件。它通过连接池来实现负载均衡与故障转移,通过阻塞的收发来实现超时处理。 异步RPC-client的核心组件是什么? 异步RPC-client的核心组件是序列化组件、连接池组件、收发队列、收发线程、上下文管理器、超时管理器。它通过“请求id”来关联请求包-响应包-回调函数,用上下文管理器来管理上下文,用超时管理器中的timer触发超时回调,推进业务流程的超时处理。

    2019-02-27
    10
  • 关于负载均衡

    负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据均匀分摊到多个操作单元上执行,其的关键在于均匀: • 反向代理层的负载均衡,是通过“DNS轮询”实现的 • 站点层的负载均衡,是通过“nginx”实现的 • 服务层的负载均衡,是通过“服务连接池”实现的 • 数据层的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”

    2018-11-19
    6
  • 微服务设计

    • 每个服务都是一个轻量级、独立和松散耦合的业务单元。 • 每个服务都有自己的代码库,由一个小团队管理和开发(主要是用于敏捷环境中)。 • 每个服务负责一部分功能或者说业务能力,并且做得很好。 • 每个服务都可以为其用例选择最佳的技术栈(无需将整个应用程序绑定在一个框架中)。 • 每个服务都有自己的DevOps计划(测试、发布、部署、扩展、集成和独立维护)。 • 每个服务都部署在一个独立自给的环境中。 • 服务通过使用定义良好的API(智能端点)和简单协议如基于HTTP 的REST协议(哑管道)相互通信。 • 每个服务负责持久化自己的数据和保持外部状态(只有当多个服务使用相同的数据时,这种情况才在公共数据层中处理)。

    2018-11-09
    1
关注 私信 TA的资源