【转】ProcessOn 划时代性的在线作图工具

[不指定 2014/07/25 17:21 | by ipaddr ]

ProcessOn是一款专业作图人员的社交网络，这里汇聚很多业界专家、学者，同时他们分享的作品又形成一个庞大的知识图库，你在学习专业知识的同时还可以结交一些志同道合的新朋友。

ProcessOn核心设计器采用HTML5 canvas、JavaScript等技术完成，它跟Visio这类传统的软件最大的区别就是无需下载和安装，更不用激活，即开即用。操作起来极为方便和简单，你可以在浏览器中简单拖拖拽拽，即可完成作图，相当人性化，ProcessOn还支自动时保存和实时协作，通过HTML5独特的技术做到毫无延迟，允许多个用户同时对同一文件进行协作编辑和多人聊天。

随着时间推进和技术的发展，如今在线应用型产品越来越受关注和重视，这在一定程度上折射出互联网的发展趋势：WEB化和移动化，传统的软件必将在未来几年被WEB应用所替代，相信不久的将来也一定会出现更多在线版的传统软件。再延伸地去说，浏览器已经开始被赋予越来越重的责任和使命，想象一下现在所有的软件将来都会被“装进”浏览器中，这个趋势谁也改变不了。ProcessOn的崛起也必将在不久的将来取代现在传统专业作图工具的市场份额和地位！一个浏览器，一个窗口，全部搞定。

使用了一会，感觉很不错，期待会有数据相关展示控件，在我看来ProcessOn是一个动词，开始吧，On一下！

ProcessOn：www.ProcessOn.com

Net | 评论(0) | 引用(0) | 阅读(98552)

twemproxy (nutcracker) 介绍

[不指定 2014/07/21 11:28 | by ipaddr ]
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcached andredis protocol. It was primarily built to reduce the connection count on the backend caching servers.

https://github.com/twitter/twemproxy

Ipaddr注： twemproxy的目的不是为了提升性能、容灾，而是为了减少Redis/Memcached的连接数。

Features

  • Fast.
  • Lightweight.
  • Maintains persistent server connections.
  • Keeps connection count on the backend caching servers low.
  • Enables pipelining of requests and responses.
  • Supports proxying to multiple servers.
  • Supports multiple server pools simultaneously.
  • Shard data automatically across multiple servers.
  • Implements the complete memcached ascii and redis protocol.
  • Easy configuration of server pools through a YAML file.
  • Supports multiple hashing modes including consistent hashing and distribution.
  • Can be configured to disable nodes on failures.
  • Observability through stats exposed on stats monitoring port.
  • Works with Linux, *BSD, OS X and Solaris (SmartOS)
SA | 评论(0) | 引用(0) | 阅读(103067)

服务器名字指示SNI(Server Name Indication)

[不指定 2014/07/17 19:32 | by ipaddr ]
Server Name Indication是用来改善SSL(Secure Socket Layer)和TLS(Transport Layer Security)的一项特性。它允许客户端在服务器端向其发送证书之前请求服务器的域名。这对于在虚拟主机模式使用TLS是必要的。
TLS背景
加密一个面向流的通讯会话最常用的方法之一就是使用TLS协议。比如，当用户在浏览器的地址栏里面输入https时就是在使用这个协议。
为了确认用户想要连接的站点就是浏览器实际连接到的站点，TLS使用包含站点域名的数字签名证书。客户端软件(比如浏览器)通常信任这个证书，如果这个证书是由其内置信任的认证机构签发的。
在TLS启动阶段，客户端软件比较用户输入的URI的域名部分与在服务器证书里面找到的域名部分，如果比较失败，浏览器会提示用户，这个站点的证书存在问题。
缺点
SSL v2的设计顺应经典的公钥基础设施PKI(public key infrastructure)设计，后者认为一个服务器只提供一个服务从而也就只使用一个证书。这意味着服务器可以在TLS启动的早期阶段发送或提交证书，因为它知道它在为哪个域服务。
HTTP服务器开启虚拟主机支持后，每个服务器通过相同的地址可以为很多域提供服务。服务器检查每一个请求来决定它在为哪个域服务。这个信息通常从HTTP请求头获得。不幸的是，当设置了TLS加密，服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书，也就是已经为默认域提供了服务。
因此，这种为虚拟主机提供安全的简单途径经常导致使用了错误的数字证书，从而导致浏览器对用户发出警告。
钓鱼连接
实际上，这意味着每一个HTTP服务器只能为一个域提供安全浏览。而事实上每一个web服务器都为很多域提供服务，结果就是其他的域无法使用安全通信，从而处于危险境地。此外，安全浏览的缺乏使浏览器无法认证服务器，亦即它无法校验站点是否真的是属于宣称它的那个人或实体。钓鱼的一个重要因素是他们企图通过虚假站点来获取用户的信息。使用SSL或者TLS安全连接，浏览器可以基于它的证书来认证站点。钓鱼站点不会作为一个欺骗性的站点得到认证，浏览器会警告这个安全风险。然而，没有安全HTTP就没有标准的方法去认证服务器，使这种钓鱼的企图很容易就能实现。
修正
一个叫做SNI的TLS扩展通过发送虚拟域的名字做为TSL协商的一部分修正了这个问题。这会使服务器更早的切换到正确的虚拟域，并且发送给浏览器包含正确名字的数字证书。
行动
在2005年，人们意识到从SSL v2到TLS没有很容易的升级路径，并且站点不得不升级他们的软件来。为了尽快的推进，Mozilla宣告完全抛弃对SSL v2的支持。Firefox社区确信其余的站点会升级他们的服务器到SSL v3或TLS v1。
从2005年开始，CAcert在虚拟服务器上用不同的方法使用TLS来进行试验，大部分试验是不满意并且不实际的。比如，可以使用subjectAltName在一个数字证书中包含多个域，但是这是一个证书，意味着所有的域必须被一个人拥有并控制，并且每次域列表发生变化，证书必须重新发放。
2004年，EdelKey project为OpenSSL里面的TLS/SNI开发了一个补丁。2006年这个补丁进入OpenSSL的开发分支，2007年，它被向后移植到了OpenSSL 0.9.8，也就是当前的发行版本。
支持状况
支持SNI的浏览器
* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
* Internet Explorer 7 (Vista, not XP) or later
* Google Chrome (Vista, not XP)
* Safari 3.2.1 Mac OS X 10.5.6
支持SNI的服务器
* Apache 2.2.12 or later using mod_ssl (or alternatively with experimental mod_gnutls)
* Cherokee if compiled with TLS support
* Versions of lighttpd 1.4.x and 1.5.x with patch
* Nginx with an accompanying OpenSSL built with SNI support
* acWEB with OpenSSL 0.9.8j and later (on Windows)
支持SNI的库
* Mozilla NSS 3.11.1 client side only
* OpenSSL
0.9.8f (released 11 Oct 2007) – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
0.9.8j (released 07 Jan 2009) – now compiled in by default
Unreleased 0.9.9 is likely to include SNI compiled in by default.
* GNU TLS
不支持SNI的操作系统,浏览器和库
客户端
* Windows XP and Internet Explorer
* Konqueror/KDE in any version
服务器端
* Microsoft Internet Information Server IIS (As of 2009).
库
* Qt
* Mozilla NSS server side
* Python
------------------------------------------
ipaddr注：
------------------------------------------
语言支持能力：
JavaSE 7+ & HttpClient 4.3.2+
PHP 5.3.2 + openssl 0.9.8f+
工具支持能力：
curl 7.18.1+ & openssl 0.9.8j+  
wget 1.14+ & openssl 0.9.8j+  
(单向认证的情况下，低版本curl可以通过-k参数来规避，低版本wget可以通过--no-check-certificate来规避，但双向认证只能升级新版本）
其它支持情况，请参考： http://en.wikipedia.org/wiki/Server_Name_Indication
Net | 评论(0) | 引用(0) | 阅读(102916)

Redis知识汇总[转]

[不指定 2014/07/15 19:41 | by ipaddr ]

https://github.com/springside/springside4/wiki/Redis

1. Overview
1.1 资料
    - <The Little Redis Book> ，最好的入门小册子，可以先于一切文档之前看，免费。
    - 作者Antirez的博客，Antirez维护的Redis推特。
    - Redis 命令中文版， huangz同学的翻译，同时还有Redis官网几篇重要文档的翻译。
    - Redis设计与实现 ，又是huangz同学的巨作，深入了解内部实现机制。
    - Redis 2.6源码中文注释版 ，继续是huangz同学的大功德。
    - NoSQL Fan里的Redis分类
    - 《Redis in Action》 (Manning, 2013) 挺实战的一本书。
1.2 优缺点

非常非常的快，有测评说比Memcached还快(当大家都是单CPU的时候)，而且是无短板的快，读写都一般的快，所有API都差不多快，也没有MySQL Cluster、MongoDB那样更新同一条记录如Counter时慢下去的毛病。

丰富的数据结构，超越了一般的Key-Value数据库而被认为是一个数据结构服务器。组合各种结构，限制Redis用途的是你自己的想象力，作者自己捉刀写的用途入门。

因为是个人作品，Redis2.6版只有2.3万行代码，Keep it simple的死硬做法，使得普通公司而不需淘宝那个级别的文艺公司也可以吃透它。 Redis宣言就是作者的自白，我最喜欢其中的“代码像首诗”，”设计是一场与复杂性的战斗“，“Coding是一件艰苦的事情，唯一的办法是享受它。如果它已不能带来快乐就停止它。为了防止这一天的出现，我们要尽量避免把Redis往乏味的路上带。”

让人又爱又恨的单线程架构，使得代码不用处理平时最让人头痛的并发而大幅简化，也不用老是担心作者的并发有没有写对，但也带来单CPU的瓶颈，而且单线程被慢操作所阻塞时，其他请求的延时变得不确定。

那Redis不是什么？

    - Redis 不是Big Data，数据都在内存中，无法以T为单位。
    - 在Redis 3.0的Redis-Cluster发布并被稳定使用之前，Redis没有真正的平滑水平扩展能力。
    - Redis 不支持Ad-Hoc Query，提供的只是数据结构的API，没有SQL一样的查询能力。
SA | 评论(0) | 引用(0) | 阅读(103275)

Redis运维实践

[不指定 2014/07/15 19:25 | by ipaddr ]
彩票业务的核心流程使用了Redis来实现消息队列，近期在世界杯的影响下，业务爆发式增长，给各组件尤其是Redis的运维也提出了新的挑战，简单整理一下运维过程中的一些心得：

Redis是什么？

Redis是一个快速，小巧，简单，但又十分强大的K/V组件；
（http://www.iamadmin.com/ 原创，转载请注明)
主要特性：
  • 所有数据都在内存中。 
  • 多种的数据结构：String / Hash / List / Set / Ordered Set。 
  • 数据过期时间支持。 
  • 不完全的事务支持。 
  • 服务端脚本：使用Lua Script编写，类似存储过程的作用。 
  • PubSub：捞过界的消息一对多发布订阅功能，起码Redis-Sentinel使用了它。 
  • 持久化：支持定期导出内存的Snapshot 与 记录写操作日志的Append Only File两种模式。 
  • Replication：Master-Slave模式，Master可连接多个只读Slave，暂无专门的Geographic Replication支持。 
  • Fail-Over：Redis-Sentinel节点负责监控Master节点，在master失效时提升slave，独立的仲裁节点模式有效防止脑裂。 
  • Sharding：开发中的Redis-Cluser。 
  • 动态配置：所有参数可用命令行动态配置不需重启，并重新写回配置文件中，对云上的大规模部署非常合适。

为什么要用Redis？

类似的KV组件非常多，业界有非常出名的Memcached、MongoDB，公司有大名鼎鼎的CKV；但Redis应用场景不止是简单的cache，与它们相比，个人觉得Redis的最大特色是拥有非常丰富的数据类型，比如新浪微博曾维护世界上最大的Redis来存储他们的关系链，消息队列；这是其它KV组件所无法实现的功能；
此外，Redis的持久化、复制功能等功能也非常完备，大大提升了组件本身的可用性；

Redis的缺陷？

Redis也不是完美的，同样存在一些使用限制：
  • 异常IO+单进程模型：由单个进程对外提供服务，一些内部异步操作（例如持久化，复制）通过fork+copy on write来实现，单进程模型最大的优点就是简单、高效，但带来的问题就是同时只有一个请求被处理；如果单个操作延时较大，或是单个客户端死循环的方式读写的话，必然会堵塞其它请求；程序设计时需要重点考虑这个限制，避免单个复杂操作或死循环式读写；
  • 数据全部存储在内存，优点还是简单、快速；缺点是内存成本较高并且单机有上限，稍不注意会有OOM Killer的风险；解决方案主要有：
    • 数据水平、垂直拆分，集群化管理；新版的Reids 3.0自带了cluster功能，当前仍是Beta阶段，稳定性未知；
    • 程序识别冷热数据，并将冷数据落地到其它组件；

Redis监控

Redis不仅仅是Cache，通常情况下还存储了相当多的业务第一手数据，所以对Redis的可用性、可靠性要求非常高；除了优化Redis本身的配置，还需要监控Redis运行情况，为排障、优化、预警提供数据；
组件本身有相当多的统计数据，可以通过info指令获取，我们通过脚本，每分钟获取info输出，再进行对比和分析，就可以实现有效的监控；
当前我们监控的主要数据有：
  • Redis当前已连接客户端  
  • Redis堵塞连接客户端 
  • Redis使用内存数(M) 
  • Redis占用内存数(M) 
  • Redis未保存操作次数 
  • Redis当前周期新连接数
  • Redis当前周期处理命令数
当前我们监控的主要异常有：
  • Redis无法连接； 
  • Redis角色为slave，但是同步中断； 
  • Redis角色为master时，所属的slave增加或减少都会有异常通知； 
  • Redis使用内存数，超过物理内存80%

常见错误：

1. 连接数不够
当前彩票架构还没有做到服务化，导致所有PHP进程都是直连Redis，且考虑到一些后台服务需要频率连接Redis而使用了pconnect，带来的问题就是Redis连接数非常多；
Redis在2.6以前，连接数限制在10240，如果在增加的话需要修改程序重编，在2.6之后组件自身没有做限制；
操作系统层面还有程序的FD限制，请在启动Redis前或系统初始化的时候设置ulimit -n；
架构设计时，需要重点考虑连接数问题，即使在2.6+后无连接数限制，也应该将业务尽量服务化，收敛业务逻辑以及到Redis，DB，Memcached等组件的连接；
2. 无法持久化或复制
当Redis内存使用量约超过物理内存一半时，Redis在fork进程进行bgsave时将会失败，此时无法rdb持久化以及新slave同步将失败，通常在日志中可以看到：
Can't save in background: fork: Cannot allocate memory
这种情况，可以将Linux的 vm.overcommit_memory = 1，但理论上也会存在风险，如果在rdb dump期间业务有相当多的数据更新，将会导致系统内存不足而发生OOM；
3. 持久化时请求被堵塞
虽然持久化时会fork进程出来，避免主进程堵塞，但大量的磁盘IO仍然会影响系统负载，导致处理性能严重下降，业务请求受到堵塞；
为避免给业务带来影响，通常做法有：
  • 在master上面关闭持久化，但需要特别注意，master挂掉后，不能自动拉起进程，否则所有数据都会被清空，slave也不能幸免；
  • 配置调优，修改no-appendfsync-on-rewrite，appendfsync两个参数，可以一定程度缓解IO压力；
总体来看，Redis是一个很棒的KV组件，在性能、稳定性、持久化、可用性方面都表现非常出色，但也需要正确使用和优化。

附：

Redis 2.8新特性
  • Slaves 能够和master部分重新同步,所以不用再担心网络瞬断导致master重新向各个 slaves发送完整的RDB文件的彻底的重新同步了。
  • 增加了IPv6支持
  • 添加了slaves 能够明确的ping master,master也能够独立的检测每个slave的超时
  • 当没有足够的给出最大延时的slave链接时，master可以停止接收写操作
  • 设置了进程的名字，方便使用ps命令输出时候能够辨别实例的监听端口或者是一个saveing的子进程
  • 能够绑定多个IP地址
  • 实现了配置重写，当使用CONFIG SET命令修改配置之后使用CONFIG REWRITE的能够同时将配置文件修改。
Redis 2.6新特性
  • 支持lua脚本。
  • VM（虚拟内存）去掉了。
  • 对于client的limit限制变成无限制。
  • aof性能提升了不少。
  • key的过滤时间可以支持毫秒级别了，原来是秒。
  • list与hash 的属性filed或value包含小整数，内存优化列好（使用了jemalloc，以前是malloc）。
  • 提供了BITCOUNT与BITOP，前者支持位值count，后者支持了位操作。（以前只支持key-value 的置位操作）
  • 支持新命令dump以及restore ，即序列化与反序列化操作。
  • 大数据存储性能优化
SA | 评论(0) | 引用(0) | 阅读(102045)
分页： 1/1 第一页 1 最后页 [ 显示模式： 摘要 | 列表 ]