科技新闻

开发自定义控件的步骤: 1、了解View的工作原理 2、 编写继承自View的子类 3、 为自定义View类增加属性 4、 绘制控件 5、 响应用户消息 6 、自定义回调函数 一、View结构原理 Android系统的视图结构的设计也采用了组合模式，即View作为所有图形的基类，Viewgroup对View继承扩展为视图容器类。 View定义了绘图的基本操作 基本操作由三个函数完成：measure()、layout()、draw()，其内部又分别包含了onMeasure()、onLayout()、onDraw()三个子方法。具体操作如下： 1、measure操作 measure操作主要用于计算视图的大小，即视图的宽度和长度。在view中定义为final类型，要求子类不能修改。measure()函数中又会调用下面的函数： （1）onMeasure()，视图大小的将在这里最终确定，也就是说measure只是对onMeasure的一个包装，子类可以覆写onMeasure()方法实现自己的计算视图大小的方式，并通过setMeasuredDimension(width, height)保存计算结果。 2、layout操作 layout操作用于设置视图在屏幕中显示的位置。在view中定义为final类型，要求子类不能修改。layout()函数中有两个基本操作： （1）setFrame（l,t

Astrotrain概述 Astrotrain是基于阿里巴巴开源项目RocketMQ进行封装的分布式消息中间件系统，提供集群环境下的消息生产和消费功能。 RocketMQ介绍 RocketMQ的物理部署结构 Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。所有的主题和broker节点信息都由Name Server进行维护。 Broker 是主要的功能单元，处理主题的存储和消费逻辑，Broker会定时同步所有信息至Name Server。 一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。 一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。Consumer群组内多应用之间消息消费是竞争关系，Consumer群组之间是共享消费，这点非常重要。 RocketMQ存储特点 Broker上绑定具体的Topic。 Topic下有多个物理存储队列(Queue)，所有存储队列都会存储消息，一个消息只会存储一份。Topic可以分布在不同Broker上。 存储队列的选择决定了消费的特性，如果只读写一个队列，那么消费就是顺序的了，否则会是无序的。 消费者Push和Pull的区别 Push模式下的消息是由事件触发，有消息到达时监听器会被调用(MessageListener)。

1. 什么是RocketMQ？ 　　 　　 　　是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。 　　Producer、Consumer、队列都可以分布式。 　　 Producer 吐一些队列轮流収送消息，队列集合称为Topic，Consumer 如果做广播消费，则一个consumer 　　实例消费返个Topic 对应的所有队列，如果做集群消费，则多个Consumer 实例平均消费返个topic 对应的 　　队列集合。 　　能够保证严格的消息顺序 　　提供丰富的消息拉叏模式 　　高效的订阅者水平扩展能力 　　实时的消息订阅机制 　　亿级消息堆积能力 　　较少的依赖 　　RocketMQ作为阿里巴巴的两大分布式技术之一，是一款纯java、分布式、队列模型的开源消息中间件，他参考了Java的JMS规范，但是它并没有遵循JMS的规范，经历了淘宝双十一的洗礼，在功能和性能上据说是远超ActiveMQ。 2. RocketMQ发展史 　　1. Metaq(Metamorphsis) 1.x 　　　由开源社区killme2008维护，开源社区非常活跃。 　　　github地址：https://github.com/killme2008/Metamorphosis 　　2. Metaq 2.x 　　　于2012年10月份上线，在淘宝内部被广泛使用。 　　3.

1. 事务消息原理图 　RocketMQ除了支持普通消息，顺序消息之外，还支持了事务消息。 1. 什么是分布式事务？ 　　分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. RocketMQ中分布式事务的使用 　　在RocketMQ中分布式事务执行过程分为三个阶段，RocketMQ第一阶段发送 Prepared消息 时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。当RocketMQ确认消息发送失败时，RocketMQ会定期扫描消息集群中的事物消息，如果发现了 Prepared消息 ，它会向消息发送端(生产者)确认，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。 　　实现方式： 　　Producer实现： package com.wangx.rocketmq.transaction; import org.apache.rocketmq.client

简介： RocketMQ（Metaq3.0版本改名）是一款分布式队列模型的消息中间件 特点如下： 1.保证消息顺序 2.支持消息拉取模式 3.高效的订阅者水平和扩展能力 4.实时的消息订阅机制 5.亿级的消息堆积能力 RocketMQ低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性： 1.强调集群无单点，可扩展，任意一点高可用，水平可扩展。 2.海量消息堆积能力，且堆积后写入低延迟。 3.支持上万个队列。（api丰富） 4.消息失败重试机制。 5.消息可查询。 6.开源社区活跃，成熟度高（双十一访问压力）。-- oceanbase 7.支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 8.在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 9.支持拉（pull）和推（push）两种消息模式 10.单一队列百万消息的堆积能力 11.支持多种消息协议，如 JMS、MQTT 等 12.分布式高可用的部署架构,满足至少一次消息传递语义 13.提供 docker 镜像用于隔离测试和云集群部署 14.提供配置、指标和监控等功能丰富的 Dashboard 专业术语 Producer 消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。 Producer

1. Exactly Only Once 　　(1). 发送消息阶段，不允许发送重复的消息 　　(2). 消费消息阶段，不允许消费重复的消息。 　　只有以上两个条件都满足情况下，才能认为消息是“Exactly Only Once”，而要实现以上两点，在分布式系统环 　　境下，不可避免要产生巨大的开销。所以RocketMQ 为了追求高性能，并不保证此特性，要求在业务上进行去重，也就是说消费消息要做到幂等性。RocketMQ 虽然不能严格保证不重复，但是正常情况下很少会出现重复发送、消 费情况，只有网络异常，Consumer 启停等异常情况下会出现消息重复。 　　此问题的本质原因是网络调用存在不确定性，即既不成功也不失败的第三种状态，所以才产生了消息重复性问 题。 2. 重复消费的原因 　　在于回馈机制。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个ACK确认信息给消息队列(broker)，消息队列(broker)就知道该消息被消费了，就会将该消息从消息队列中删除。 不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念。 　　造成重复消费的原因?，就是因为网络原因闪断，ACK返回失败等等故障，确认信息没有传送到消息队列

今天要分享的这款jQuery消息提示框插件名叫Tipso，它的特点是可以定义提示框的显示位置，以及动态改变提示框的提示内容，应该说是一款相当灵活的jQuery消息提示框插件。效果图如下： 在线预览 源码下载 实现的代码： <div class="dowebok"> <h2> 1、默认</h2> <div class="inner"> <span id="tip1" data-tipso="dowebok.com">Tipso</span></div> </div> <div class="dowebok"> <h2> 2、左边显示</h2> <div class="inner"> <span id="tip2" data-tipso="dowebok.com">Tipso</span></div> </div> <div class="dowebok"> <h2> 3、背景颜色</h2> <div class="inner"> <span id="tip3" data-tipso="dowebok.com">Tipso</span></div> </div> <div class="dowebok"> <h2> 4、使用title属性</h2> <div class="inner"> <span id="tip4" title="内容来自 title 属性">Tipso</span

　　首先，应该怀着这样一种心态来学习Restful——Restful你可以将其理解一种软件架构风格，并且诠释了Http协议的设计初衷，所以不要把他理解的那么神秘，Restful风格有好处，当然也是有坏处的。 　　然后是正文（转的）： 在SOA的基础技术实现方式中WebService占据了很重要的地位，通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受，同时各大网站不断开放API提供给开发者，也激起了REST风格WebService的热潮。 SOAP 什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。 REST REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子

在SOA的基础技术实现方式中WebService占据了很重要的地位，通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受，同时各大网站不断开放API提供给开发者，也激起了REST风格WebService的热潮。 SOAP 什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。 REST REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查

在 SOA 的基础技术实现方式中 WebService 占据了很重要的地位，通常我们提到 WebService 第一想法就是 SOAP 消息在各种传输协议上交互。近几年 REST 的思想伴随着 SOA 逐渐被大家接受，同时各大网站不断开放 API 提供给开发者，也激起了 REST 风格 WebService 的热潮。 SOAP 什么是 SOAP ，我想不用多说， google 一把满眼都是。其实 SOAP 最早是针对 RPC 的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（ Http,SMTP 等）。但是随着 SOAP 作为 WebService 的广泛应用，不断地增加附加的内容，使得现在开发人员觉得 SOAP 很重，使用门槛很高。在 SOAP 后续的发展过程中， WS-* 一系列协议的制定，增加了 SOAP 的成熟度，也给 SOAP 增加了负担。 REST REST 其实并不是什么协议也不是什么标准，而是将 Http 协议的设计初衷作了诠释，在 Http 协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。 SOAP 类型的 WebService 就是最好的例子， SOAP 消息完全就是将 Http 协议作为消息承载，以至于对于 Http 协议中的各种参数（例如编码，错误码等）都置之不顾。其实