作者归档: 童燕群

iOS7正式版体验

昨天晚上,iPad上面忽然很多应用都提示更新,简单看了一下,都是提示针对iOS7的更新。一想,原来iOS7在9月18号正式向用户推送。犹豫了一会,到底要不要升上去,担心升上去后体验不如现在,扁平化,系统耗电量增加,这些问题在坊间早有流传。好奇心战胜了这些担忧,还是决定升级。由于上次已经从越狱版本升级到了6.1.3版本,这次可以直接在PAD上面升级,不需要到PC上面用iTunes来辅助。点击升级链接,开始下载升级镜像。但是总是不一会就提示下载失败,估计是升级的人太多的原因吧。折腾了几次就放弃了。一觉醒来已经是早上了,再次尝试,成功,看到了熟悉的“缺口苹果”。

总结一下几大更新:

1、界面图标扁平化,磨砂玻璃般透明的感觉不错;

2、应用启动动画效果有增强;

3、搜索不再独立一个桌面,而是与通知栏一样嵌在主页上面,这个改进感觉比较赞,以前总是不小心就滑动到搜索的界面上去了,不得已又要退回来;

4、键盘感觉更轻巧了,让人感觉打字时手指移动到正确的键上面要容易些;

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.50- 2票) Loading ... Loading ... | 归档目录:数码硬件 | 标签: , |

Google 公布了分布式关系数据库F1的设计论文

该分布式关系型数据库基于Spanner,F1针对AdWords业务设计,兼具NoSQL的高可用性和扩展性,主要用来替代MySQL的集群。早期的时候已经有F1的介绍文档:幻灯片 F1 – The Fault-Tolerant Distributed RDBMS Supporting Google’s Ad Business

这一次,Google公布了其设计文档,阅读链接:

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 归档目录:数据库 | 标签: , |

从数据库之“分久必合,合久必分”看大数据的发展

来自:卢东明 SAP全球数据库解决方案部 技术总监

文档链接:

从数据库之“分久必合,合久必分”看大数据的发展

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 归档目录:数据库 | 标签: , , |

JVM并发机制的探讨——内存模型、内存可见性和指令重排序

转自oschina

并发本来就是个有意思的问题,尤其是现在又流行这么一句话:“高帅富加机器,穷矮搓搞优化”。从这句话可以看到,无论是高帅富还是穷矮搓都需要深入理解并发编程,高帅富加多了机器,需要协调多台机器或者多个CPU对共享资源的访问,因此需要了解并发,穷矮搓搞优化需要编写各种多线程的代码来压榨CPU的计算资源,让它在同一时刻做更多的事情,这个更需要了解并发。

在我前一篇关于并发的文章http://my.oschina.net/chihz/blog/54731中提到过管程,管程的特色是在编程语言中对并发的细节进行封装,使程序员可以直接在语言中就得到并发的支持,而不必自己去处理一些像是控制信号量之类容易出错且繁琐的细节问题。一些语言是通过在编译时解开语法糖的方式去实现管程,但Java在编译后生成的字节码层面上对并发仍然是一层封装,比如syncrhonized块在编译之后只是对应了两条指令:monitorenter和monitorexit。更多的并发细节是在JVM运行时去处理的,而不是编译。这篇文章主要是针对JVM处理并发的一些细节的探讨。

JAVA内存模型

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 归档目录:Java, 多线程编程 | 标签: |

访问量激增,有点不适应

今天中午向http://news.dbanotes.net/提交了几个我的博客上面的链接,访问量一下子直线上升,一下午的访问量超过了几个月以来访问量的总和。可见网站内容多么重要,能留住用户真的是一件很难的事情。如果你要问访问者想看什么样的文章还真难得到明确的答案,但是大多数人对于美感,对于自己想要的样子出现时总是能不自觉就被吸引住了。继续努力,做好技术,做好博客。

Google Analytics

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 归档目录:生活札记, 移动互联 |

DNS原理、架构和配置详解

题目起得有点大,其实都是一些基础知识。工作、生活中经常被问到DNS的工作原理,这里把相关的知识点总结一下。DNS作为域名解析的规范,本身是相当简单的,但是因为我们日常工作中很难接触到,因此对其工作原理、架构和配置等就显得非常陌生。在分布式系统中,DNS更是扮演着重要的角色。名字空间和网域的划分都要依赖他。

一、我们日常网络活动能感受的域名解析服务

首先从我们日常生活中能看到的DNS模型说起,一般而言我们都知道DNS是做什么的:将容易记住的网址转换成网站的IP地址(网站,确切的说是提供web服务的主机的IP地址)。那么这一过程是如何发生的呢?下面的流程图给出了这一过程。偷点懒,图片没有自己画,都是在网络上面找来的(Google图片搜索-DNS查询)。

DNS查询示意图

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 10票) Loading ... Loading ... | 归档目录:移动互联, 软件技术 | 标签: , , , , , , |

精选实用正则表达式

匹配中文字符的正则表达式: [\u4e00-\u9fa5]
评注:匹配中文还真是个头疼的事,有了这个表达式就好办了

匹配双字节字符(包括汉字在内):[^\x00-\xff]
评注:可以用来计算字符串的长度(一个双字节字符长度计2,ASCII字符计1)

匹配空白行的正则表达式:\n\s*\r
评注:可以用来删除空白行

匹配HTML标记的正则表达式:<(\S*?)[^>]*>.*?</\1>|<.*? />
评注:网上流传的版本太糟糕,上面这个也仅仅能匹配部分,对于复杂的嵌套标记依旧无能为力

匹配首尾空白字符的正则表达式:^\s*|\s*$
评注:可以用来删除行首行尾的空白字符(包括空格、制表符、换页符等等),非常有用的表达式

匹配Email地址的正则表达式:\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*
评注:表单验证时很实用

匹配网址URL的正则表达式:[a-zA-z]+://[^\s]*
评注:网上流传的版本功能很有限,上面这个基本可以满足需求

匹配帐号是否合法(字母开头,允许5-16字节,允许字母数字下划线):^[a-zA-Z][a-zA-Z0-9_]{4,15}$
评注:表单验证时很实用

匹配国内电话号码:\d{3}-\d{8}|\d{4}-\d{7}
评注:匹配形式如 0511-4405222 或 021-87888822

匹配腾讯QQ号:[1-9][0-9]{4,}
评注:腾讯QQ号从10000开始

匹配中国邮政编码:[1-9]\d{5}(?!\d)
评注:中国邮政编码为6位数字

匹配身份证:\d{15}|\d{18}
评注:中国的身份证为15位或18位

匹配ip地址:\d+\.\d+\.\d+\.\d+

评注:提取ip地址时有用

匹配特定数字:
^[1-9]\d*$    //匹配正整数
^-[1-9]\d*$   //匹配负整数
^-?[1-9]\d*$   //匹配整数
^[1-9]\d*|0$  //匹配非负整数(正整数 + 0)
^-[1-9]\d*|0$   //匹配非正整数(负整数 + 0)
^[1-9]\d*\.\d*|0\.\d*[1-9]\d*$   //匹配正浮点数
^-([1-9]\d*\.\d*|0\.\d*[1-9]\d*)$  //匹配负浮点数
^-?([1-9]\d*\.\d*|0\.\d*[1-9]\d*|0?\.0+|0)$  //匹配浮点数
^[1-9]\d*\.\d*|0\.\d*[1-9]\d*|0?\.0+|0$   //匹配非负浮点数(正浮点数 + 0)
^(-([1-9]\d*\.\d*|0\.\d*[1-9]\d*))|0?\.0+|0$  //匹配非正浮点数(负浮点数 + 0)
评注:处理大量数据时有用,具体应用时注意修正

匹配特定字符串:
^[A-Za-z]+$  //匹配由26个英文字母组成的字符串
^[A-Z]+$  //匹配由26个英文字母的大写组成的字符串
^[a-z]+$  //匹配由26个英文字母的小写组成的字符串
^[A-Za-z0-9]+$  //匹配由数字和26个英文字母组成的字符串
^\w+$  //匹配由数字、26个英文字母或者下划线组成的字符串
评注:最基本也是最常用的一些表达式

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 归档目录:实用脚本 | 标签: , |

精选37条强大的常用linux shell命令组合

| 1 分2 分3 分4 分5 分 (5.00- 6票) Loading ... Loading ... | 归档目录:实用脚本 | 标签: , , |

二阶段提交及相关学习笔记

在分布式数据库中,处理分布式事务是比较重要的技术。分布式事务的处理保证了数据的一致性。二阶段提交在可用性和一致性性上面做到了最好的折中。是一种基本的事务处理机制或者协议。

对于二阶段提交的准确解释可以参考维基百科词条:http://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4

二阶段提交(Two-phase Commit)

理解二阶段提交关键是要结合redo、undo日志,日志可以固化到DB中,也可以回滚即丢弃,基于此,才能做到预提交与实际提交的分离。

在分布式系统中,一般来说不止是1个协调者与2~3个参与者之间交互,当考虑容错性时,通常会考虑如下场景:

协调者在完成了一阶段的预提交过程后,得出了本事务的执行结论,在本地日志中记录了结论,正待向参与者发出结论时,宕机,这样除了协调者本身之外,就没有人知道该事务的结论。因此必须等待协调者恢复之后才能继续该事务,在此之前所有参与者都将阻塞。各个阶段所获取的资源一直不释放,可能导致整个集群业务受阻。

解决该问题的办法是将第二阶段(正式提交阶段)再变为两个阶段,先让集群中若干个参与者知道自己将要提交结论,而不是记录本地日志,这样该协调者无论在哪个阶段宕机,都可以由新选出的协调者通过查询各个参与节点的状态来判断当前处于哪个阶段,从而继续后面的各个阶段的操作。也就是三阶段提交了,这样参与者与协调者的交互步骤增加,实际操作起来也变得复杂很多,因此实用性不强。

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 归档目录:软件技术 | 标签: , , |

[转] 几大分布式文件系统全方位比较

转载信息:

作者:朱荣泽
原文地址:http://blog.csdn.net/metaxen/article/details/7108958

阅读链接:

分布式文件系统MFS、Ceph、GlusterFS、Lustre的比较

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 归档目录:软件技术 | 标签: , , , , |
返回顶部