Stars永恒的博客

主流消息中间件架构模式Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。架构模式依赖zookeeperRocketMQ是阿里开源的消息中间件，目前也已经 孵化为Apache顶级项目，它是纯Java开发，具有高吞.

Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合)。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色。Dubbo是什么简单说呢，Dubbo用起来就和E

一、说在前面的话前段时间，工作上需要做一个针对视频质量的统计分析系统，各端（PC端、移动端和 WEB端）将视频质量数据放在一个 HTTP 请求中上报到服务器，服务器对数据进行解析、分拣后从不同的维度做实时和离线分析。（ps：这种活儿本该由统计部门去做的，但由于各种原因落在了我头上，具体原因略过不讲……）先用个“概念图”来描绘下整个系统的架构：嗯，这个是真正的“概念图

使用的资源：nginx主服务器一台，nginx备服务器一台，使用keepalived进行宕机切换。tomcat服务器两台，由nginx进行反向代理和负载均衡，此处可搭建服务器集群。redis服务器一台，用于session的分离共享。nginx主服务器：192.168.50.133nginx备服务器：192.168.50.135tomcat项目服务器1

前言一般而言，现在互联网应用（网站或App）的整体流程，可以概括如图1所示，用户请求从界面（浏览器或App界面）到网络转发、应用服务再到存储（数据库或文件系统），然后返回到界面呈现内容。随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，且技术变革

问：站点与服务，服务与服务上下游之间，一般如何通讯？答：有两种常见的方式一种是“直接调用”，通过RPC框架，上游直接调用下游。 在某些业务场景之下（具体哪些业务场景，见《到底什么时候该使用MQ？》），可以采用“MQ推送”，上游将消息发给MQ，MQ将消息推送给下游。 问：为什么会有流量冲击？答：不管采用“直接调用”还是“MQ推送”，都有

社交类产品对搜索功能需求要求就比较高，需要根据用户城市、用户ID昵称等进行搜索。项目原先的搜索接口采用SQL查询的方式实现，数据库表采用了按城市分表的方式。但随着业务的发展，搜索接口调用频次越来越高，搜索接口压力越来越大，搜索数据库经常崩溃，从而导致搜索功能经常不能使用。从上面的系统架构图可以看出，当用户修改资料时，接口会修改用户库信息，接着触发器会将改变的用户信息写入临时表。定时

一、缘起很多时候，业务有“在一段时间之后，完成一个工作任务”的需求。 例如：滴滴打车订单完成后，如果用户一直不评价，48小时后会将自动评价为5星。一般来说怎么实现这类“48小时后自动评价为5星”需求呢？ 常见方案：启动一个cron定时任务，每小时跑一次，将完成时间超过48小时的订单取出，置为5星，并把评价状态置为已评价。假设订单表的结构为