posts - 12, comments - 8, trackbacks - 0, articles - 5
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2010年12月3日

博客做了迁移,新的地址:观云的BLOG https://yeas.fun/
新博课主要用于记录一些系列的技术文章,今年的一个目标就是深入研究JVM底层,我会把一些学习心得记录下来,也欢迎大家一起讨论~

posted @ 2020-04-18 10:12 杨罗罗 阅读(32) | 评论 (0)编辑 收藏

现在网络那么发达,我们上网的每个人势必会在各个网站上登陆,那势必会有一堆密码需要管理,那怎么能记住那么多网站的密码呢?我之前的做法是设置几个常用的密码,好多不重要的网站用一个,重要的网站用一个,然后...CSDN密码泄露之后,只得吭哧吭哧的改一堆密码。那种痛苦真的是呵呵呵

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

那就是LastPass的工作,它是一款跨平台密码管理软件。你在每个网站上都可以随机生成一个密码,然后软件会自动记住,你只需要记住这个软件的主密码就可以了。超方便!

为什么要用LastPass?

我用LastPass,是因为它可以安装浏览器插件,之后你在网站的注册,它会自动提醒你要不要加入它的密码库,你在网站的登陆它会自动帮你填写账号密码,甚至于一些常用的表单(比如说身份证、公司地址、银行卡等)你可以提前设置好,它也会自动帮你填写,我再也不用记那么多密码了,一切都是自动化。
如果你经常有国外的帐号,比如说google等大公司,LastPass甚至提供了一键改密码的功能,好方便!

支持智能手机么?

当然!现在智能机那么流行,不能在智能机上用,简直不能忍。当你安装了IOS软件之后,在打开网站登录界面,点击下方的向上小箭头,选择LassPass软件,点击Touch ID,好了,密码自动完成,世界顿时清净了,想想以前在手机上输入超长的密码,跪了!

真的安全吗?

有的人担心密码泄露问题,其实对于LastPass没啥必要,因为LastPass存储的都是加密文件,只要你的主密码不泄露,别人即使拿到你的网上的密码,也是加密的,没法用。

它收费吗?

好东西都要收费,价格也还可以,几十块一年,其实收费版和免费版对于普通用户,最重要的区别就是:免费版帐号密码不能云同步

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

https://lastpass.com/f?18430702  通过这个地址注册,则会免费获得一个月高级账户权限

最后也是最重要的:

点击这个链接,输入刚刚你注册的邮箱,则会送半年的高级账户,记住一个密码,就记住了所有密码,就是那么简单!

posted @ 2016-01-13 14:19 杨罗罗 阅读(227) | 评论 (0)编辑 收藏

一. 应用场景

在大型分布式应用中,我们经常碰到在多数据库之间的数据同步问题,比如说一款游戏,在玩家注册后,可以马上登陆进入服务器,数据在一个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),处理流程为:

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

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

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

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

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

数据同步流程

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

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

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

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格式

value格式

备注

redis原始数据

sync:<业务类型>:<sid>

{"ctime":65711321800,"v":1,"data":"hello world"}

分站没有此项

redis业务附加任务

sync:<业务类型>:<sid>:sub

set类型,保存需要同步的节点id,例如[1,3,5]

分发确认Set数据结构 

httpsqs队列

sync:<业务类型> 
sync:<业务类型>:retry 
sync:<业务类型>:death

{"sid":111,"type":"pp_register","exec":1} 

中心队列内容,key中<业务类型>是可选项 

httpsqs队列

sync:<业务类型> 
sync:<业务类型>:retry 
sync:<业务类型>:death

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

分站队列内容,包含业务数据 

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

五.编码及测试结果

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

posted @ 2011-04-06 15:50 杨罗罗 阅读(3218) | 评论 (3)编辑 收藏

     摘要: java.util.concurrent 包含许多线程安全、测试良好、高性能的并发构建块。不客气地说,创建 java.util.concurrent 的目的就是要实现 Collection 框架对数据结构所执行的并发操作。通过提供一组可靠的、高性能并发构建块,开发人员可以提高并发类的线程安全、可伸缩性、性能、可读性和可靠性。 如果一些类名看起来相似,可能是因为 java.util.concurr...  阅读全文

posted @ 2010-12-08 17:40 杨罗罗 阅读(707) | 评论 (0)编辑 收藏

AQS中有一个state字段(int类型,32位)用来描述有多少线程获持有锁。在独占锁的时代这个值通常是0或者1(如果是重入的就是重入的次数),在共享锁的时代就是持有锁的数量。
自旋等待适合于比较短的等待,而挂起线程比较适合那些比较耗时的等待。

锁竞争

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

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

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

死锁

1.一种情况是线程A永远不释放锁,结果B一直拿不到锁,所以线程B就“死掉”了
2.第二种情况下,线程A拥有线程B需要的锁Y,同时线程B拥有线程A需要的锁X,那么这时候线程A/B互相依赖对方释放锁,于是二者都“死掉”了。
3.如果一个线程总是不能被调度,那么等待此线程结果的线程可能就死锁了。这种情况叫做线程饥饿死锁。比如说非公平锁中,如果某些线程非常活跃,在高并发情况下这类线程可能总是拿到锁,那么那些活跃度低的线程可能就一直拿不到锁,这样就发生了“饥饿死”。

避免死锁的解决方案是:
1.尽可能的按照锁的使用规范请求锁,另外锁的请求粒度要小(不要在不需要锁的地方占用锁,锁不用了尽快释放);
2.在高级锁里面总是使用tryLock或者定时机制(就是指定获取锁超时的时间,如果时间到了还没有获取到锁那么就放弃)。高级锁(Lock)里面的这两种方式可以有效的避免死锁。

posted @ 2010-12-03 10:11 杨罗罗 阅读(1632) | 评论 (0)编辑 收藏