那有没有什么方式可以方便的管理密码呢？

为什么要用LastPass?

支持智能手机么？

真的安全吗？

它收费吗？

免费获得一个月的高级账户权限

最后也是最重要的：

一. 应用场景

在大型分布式应用中，我们经常碰到在多数据库之间的数据同步问题，比如说一款游戏，在玩家注册后，可以马上登陆进入服务器，即数据在一个IDC更新，其它IDC立即可见。为了简化思路，我们这里称玩家注册的数据库(数据来源库)为中心库，同步目的地的数据库为分站库。

在分布式领域有个CAP理论，是说Consistency(一致性), Availability(可用性), Partition tolerance(分区和容错) 三部分在系统实现只可同时满足二点，无法三者兼顾。

能做的

· 数据快速搬运到指定的IDC节点

· 数据传递过程中失败时，重新传递

· 监控数据传递流程

· 故障转移

· 数据版本控制

· 分配全局唯一的ID

不能做的

· 不参与业务行为，业务操作只能通过注册的方式集成

· 不保存业务数据，不提供传递的业务的查询

二．系统要求

1.数据快速同步：除去网络原因，正常情况下从来源库同步到接收库的时间不超过300m2.高并发：单个应用每秒同步2000条记录
3.可伸缩性，在资源达到上限时能通过增加应用分散处理后期增长的压力
4.数据完整性要求，在数据同步过程中保证数据不丢失和数据安全
5.故障转移和数据恢复功能

三．设计思路

系统优化，最常用的就是进行业务切割，将总任务切割为许多子任务，分区块分析系统中可能存在的性能瓶颈并有针对性地进行优化，在本系统中，主要业务包含以下内容：
1.Syncer：外部接口，接收同步数据请求，初始化同步系统的一些必要数据
2.Delivery：将同步数据按照业务或优先级进行分发，并记录分发结果
3.Batch：分站库收到同步数据后，根据不同的业务类型调用相应的业务逻辑处理数据
基于以上三块业务功能，我们可以把整个数据同步流程切割为3个应用，具体如下图显示。在Syncer端应用中，我们需要将原始同步数据和分发的分站进行存储，以备失败恢复，此时如果采用数据库进行存储，势必会受限于数据库性能影响，因此我们采用了高效的key-value风格存储的redis服务来记录数据，同时在不同应用之间采用队列(Httpsqs服务)的方式来进行通讯，同时也保证的数据通讯的顺序性，为之后的顺序同步做好基础。
Httpsqs提供了http风格的数据操作模式，业务编码非常简单，同时也提供了web形式的队列处理情况查询，这是选择它做队列服务很大一部分原因：方便业务操作和性能监控。

四．数据流转 

绿色-正常流程、红色-异常流程

队列处理

根据业务划分队列名称，每个队列再划分为三个关联队列：正常队列(Normal)、重试队列(Retry)、死亡队列(Death)，处理流程为：

1 【进程A】把数据先放入正常队列，如果放置失败写恢复日志

2 【进程B】监听正常队列，获取队列数据并进行业务处理，处理失败放入重试队列

3 【进程C】监听重试队列，过几秒获取队列数据并重新进行业务处理，处理失败放入死亡队列

4 【进程D】监听死亡队列，获取队列数据并重新进行业务处理，处理失败重新放入死亡队列尾部，等待下一次轮回

业务处理失败如果无法再次放入队列，记录恢复日志

数据同步流程

1发送数据，支持Http POST：curl -d "经过URL编码的文本消息"，如"http://host:port/sync_all/register"
或者Http GET：curl "http://host:port/sync_all/register?data=经过URL编码的文本消息"

5 sync-syncer接收到同步数据请求，创建sid并分解出需要同步的节点个数，把原始数据和子任务写入redis中，sid写入httpsqs中

6 sync-delivery监听中心httpsqs队列，根据sid从redis获取到原始数据和需要同步的节点地址，往其他节点发送数据，流程如按"队列处理流程"进行

7 sync-batch监听分节点的httpsqs队列，调用已经注册的处理器处理队列数据，流程如按"队列处理流程"进行

三. 恢复和监控

恢复数据源

· httpsqs中的死亡队列 - 业务处理暂时处理不了的数据

· recovery日志文件 - 其它异常情况下的数据，例如网络无法连接、内部服务不可用

数据恢复

独立的应用来处理正常流程中没有完成的任务，主要功能有：

· 监听死亡队列，进行业务重做，再次执行失败时将执行次数+1，最大执行次数为5(默认)，超出上限则记录到恢复日志中

· 读取恢复日志，重新放入死亡队列

应用监控

· 使用scribe日志框架服务业务日志的采集和监控

· 收集重要的业务操作日志

· 动态的开启/关闭某类业务日志

· 对redis进行监控

· 对httpsps，监控队列个数，每个队列的状态

四. 数据结构

{"sid":111,"type":"reg","v":1,"data":"hello world","ctime":65711321800,"exec":1}

· sid(sync id) - 全局唯一id

· v(version) - 版本号

· data - 业务数据

· ctime(create time) - 创建时间(毫秒)

· exec - 可选，执行次数

所有的key都小写，以 ':' 作为分隔符

五．编码及测试结果

经过编码和测试，在内网环境下，在无数据库限制的情况下，单应用可以传递1500条/秒，基本满足业务需求。如果需进一步扩展，采用集群式布署可使得吞吐量成倍的增长。

锁竞争

影响锁竞争性的条件有两个：锁被请求的频率和每次持有锁的时间。显然当而这二者都很小的时候，锁竞争不会成为主要的瓶颈。但是如果锁使用不当，导致二者都比较大，那么很有可能CPU不能有效的处理任务，任务被大量堆积。

所以减少锁竞争的方式有下面三种：

1. 减少锁持有的时间
2. 减少锁请求的频率
3. 采用共享锁取代独占锁

Spring中提供一些Aware相关接口，像是BeanFactoryAware、 ApplicationContextAware、ResourceLoaderAware、ServletContextAware等等，实现这些 Aware接口的Bean在被初始之后，可以取得一些相对应的资源，例如实现BeanFactoryAware的Bean在初始后，Spring容器将会注入BeanFactory的实例，而实现ApplicationContextAware的Bean，在Bean被初始后，将会被注入 ApplicationContext的实例等等。

　Bean取得BeanFactory、ApplicationContextAware的实例目的是什么，一般的目的就是要取得一些档案资源的存取、相 关讯息资源或是那些被注入的实例所提供的机制，例如ApplicationContextAware提供了publishEvent()方法，可以支持基于Observer模式的事件传播机制。

　ApplicationContextAware接口的定义如下：

ApplicationContextAware.java

public interface ApplicationContextAware {

    void setApplicationContext(ApplicationContext context);

}

　我们这边示范如何透过实现ApplicationContextAware注入ApplicationContext来实现事件传播，首先我们的HelloBean如下：

HelloBean.java

package onlyfun.caterpillar;

import org.springframework.context.*;

public class HelloBean implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    private String helloWord = "Hello!World!";

    public void setApplicationContext(ApplicationContext context) {

        this.applicationContext = context;

    }

    public void setHelloWord(String helloWord) {

        this.helloWord = helloWord;

    }

    public String getHelloWord() {

        applicationContext.publishEvent(

               new PropertyGettedEvent("[" + helloWord + "] is getted"));

        return helloWord;

    }

}

　ApplicationContext会由Spring容器注入，publishEvent()方法需要一个继承ApplicationEvent的对象，我们的PropertyGettedEvent继承了ApplicationEvent，如下：

PropertyGettedEvent.java

package onlyfun.caterpillar;

import org.springframework.context.*;

public class PropertyGettedEvent extends ApplicationEvent {

    public PropertyGettedEvent(Object source) {

        super(source);

    }

}

　当ApplicationContext执行publishEvent()后，会自动寻找实现ApplicationListener接口的对象并通知其发生对应事件，我们实现了PropertyGettedListener如下：

PrppertyGettedListener.java

package onlyfun.caterpillar;

import org.springframework.context.*;

public class PropertyGettedListener implements ApplicationListener {

    public void onApplicationEvent(ApplicationEvent event) {

        System.out.println(event.getSource().toString());  

    }

}

　Listener必须被实例化，这我们可以在Bean定义档中加以定义：

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE beans PUBLIC "-//SPRING/DTD BEAN/EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

    <bean id="propertyGetterListener" class="onlyfun.caterpillar.PropertyGettedListener"/>

    <bean id="helloBean" class="onlyfun.caterpillar.HelloBean">

        <property name="helloWord"><value>Hello!Justin!</value></property>

    </bean>

</beans>

　我们写一个测试程序来测测事件传播的运行：

Test.java

package onlyfun.caterpillar;

import org.springframework.context.*;

import org.springframework.context.support.*;

public class Test {

    public static void main(String[] args) {

        ApplicationContext context = new ClassPathXmlApplicationContext("bean.xml");

        HelloBean hello = (HelloBean) context.getBean("helloBean");

        System.out.println(hello.getHelloWord());

    }

}

　执行结果会如下所示：

log4j:WARN No appenders could be found for logger

(org.springframework.beans.factory.xml.XmlBeanDefinitionReader).

log4j:WARN Please initialize the log4j system properly.

org.springframework.context.support.ClassPathXmlApplicationContext:

displayName=[org.springframework.context.support.ClassPathXmlApplicationContext;

hashCode=33219526]; startup date=[Fri Oct 29 10:56:35 CST 2004];

root of ApplicationContext hierarchy

[Hello!Justin!] is getted

Hello!Justin!

　以上是以实现事件传播来看看实现Aware接口取得对应对象后，可以进行的动作，同样的，您也可以实现ResourceLoaderAware接口：

ResourceLoaderAware.java

public interface ResourceLoaderAware {

    void setResourceLoader(ResourceLoader loader);

}

　实现ResourceLoader的Bean就可以取得ResourceLoader的实例，如此就可以使用它的getResource()方法，这对于必须存取档案资源的Bean相当有用。

　基本上，Spring虽然提供了这些Aware相关接口，然而Bean上若实现了这些界面，就算是与Spring发生了依赖，从另一个角度来看，虽然您可以直接在Bean上实现这些接口，但您也可以透过setter来完成依赖注入，例如：

HelloBean.java

package onlyfun.caterpillar;

import org.springframework.context.*;

public class HelloBean {

    private ApplicationContext applicationContext;

    private String helloWord = "Hello!World!";

    public void setApplicationContext(ApplicationContext context) {

        this.applicationContext = context;

    }

    public void setHelloWord(String helloWord) {

        this.helloWord = helloWord;

    }

    public String getHelloWord() {

        applicationContext.publishEvent(new PropertyGettedEvent("[" + helloWord + "] is getted"));

        return helloWord;

    }

}

　注意这次我们并没有实现ApplicationContextAware，我们在程序中可以自行注入ApplicationContext实例：

ApplicationContext context = new ClassPathXmlApplicationContext("bean.xml");

HelloBean hello = (HelloBean) context.getBean("helloBean");

hello.setApplicationContext(context);

System.out.println(hello.getHelloWord());

　就Bean而言，降低了对Spring的依赖，可以比较容易从现有的框架中脱离。