分类目录归档:technologys

Git命令

Git命令 Git 是一个很强大的分布式版本控制系统。它不但适用于管理大型开源软 … 继续阅读

发表在 technologys | 标签为 | Git命令已关闭评论

Intel Xeon 5000 / E3 / E5 / E7

处理器型号 内核数 GPU 核心数 CPU频率 (GHz) 高速缓存 (MB) … 继续阅读

发表在 technologys | 标签为 | Intel Xeon 5000 / E3 / E5 / E7已关闭评论

LDAP

1. LDAP简介 LDAP(轻量级目录访问协议,Lightweight Dir … 继续阅读

发表在 technologys | 标签为 | LDAP已关闭评论

CPU/GPU

CPU和GPU之所以大不相同,是由于其设计目标的不同,它们分别针对了两种不同的应用场景。CPU需要很强的通用性来处理各种不同的数据类型,同时又要逻辑判断又会引入大量的分支跳转和中断的处理。这些都使得CPU的内部结构异常复杂。而GPU面对的则是类型高度统一的、相互无依赖的大规模数据和不需要被打断的纯净的计算环境。

  于是CPU和GPU就呈现出非常不同的架构(示意图):

点击查看原图

  图片来自nVidia CUDA文档。其中绿色的是计算单元,橙红色的是存储单元,橙黄色的是控制单元。

GPU采用了数量众多的计算单元和超长的流水线,但只有非常简单的控制逻辑并省去了Cache。而CPU不仅被Cache占据了大量空间,而且还有有复杂的控制逻辑和诸多优化电路,相比之下计算能力只是CPU很小的一部分

点击查看原图

  从上图可以看出:

Cache, local memory: CPU > GPU

Threads(线程数): GPU > CPU

Registers: GPU > CPU  多寄存器可以支持非常多的Thread,thread需要用到register,thread数目大,register也必须得跟着很大才行。

SIMD Unit(单指令多数据流,以同步方式,在同一时间内执行同一条指令): GPU > CPU。

 

CPU 基于低延时的设计:

点击查看原图

CPU有强大的ALU(算术运算单元),它可... 继续阅读

发表在 technologys | 标签为 , | CPU/GPU已关闭评论

RPC

RPC(远程过程调用)是什么

  • 简单的说,RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
  • RPC 会隐藏底层的通讯细节(不需要直接处理Socket通讯或Http通讯)
  • RPC 是一个请求响应模型。客户端发起请求,服务器返回响应(类似于Http的工作方式)
  • RPC 在使用形式上像调用本地函数(或方法)一样去调用远程的函数(或方法)。

远程过程调用发展历程

  • ONC RPC (开放网络计算的远程过程调用),OSF RPC(开放软件基金会的远程过程调用)
  • CORBA(Common Object Request Broker Architecture公共对象请求代理体系结构)
  • DCOM(分布式组件对象模型),COM+
  • Java RMI
  • .NET Remoting
  • XML-RPC,SOAP,Web Service
  • PHPRPC,Hessian,JSON-RPC
  • Microsoft WCF,WebAPI
  • ZeroC Ice,Thrift,GRPC
  • Hprose

早期的 RPC

  • 第一代 RPC(ONC RPC,OSF RPC)不支持对象的传递。
  • CORBA 太复杂,各种不同实现不兼容,一般程序员也玩不转。
  • DCOM,COM+ 逃不出 Windows 的手掌心。
  • RMI 只能在 Java 里面玩。
  • .NET Remoting 只能在 .NET 平台上玩。

XML-...

继续阅读

发表在 technologys | RPC已关闭评论

ascii

点击查看原图


继续阅读

发表在 technologys | ascii已关闭评论

前端知识图谱

 

来源于群分享:

点击查看原图
继续阅读

发表在 technologys | 前端知识图谱已关闭评论

Google Chrome VIEW HTTP/2

Google Chrome
 
Google Chrome 中在开发者工具中看不到 HTTP/2 指示器。
 Chrome 用特殊的地址
chrome://net-internals/#http2 给出了相关信息。

chrome://net-internals/#events&q=id:336
继续阅读

发表在 technologys | Google Chrome VIEW HTTP/2已关闭评论

ALPHA,BETA,GAMMA,GA,RC,LTS 常见版本/version

(1)RC:(Release Candidate)

  Candidate是候选人的意思,用在软件上就是候选版本。Release.Candidate.就是发行候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能,但是到了RC版本,几乎就不会加入新的功能了,而主要着重于除错!

        是最终发放给用户的最接近正式版的版本,发行后改正bug就是正式版了,就是正式版之前的最后一个测试版

(2)GA:(general availability)

比如:Apache Struts 2 GA

这是Apache Struts 2首次发行稳定的版本,GA意味着General Availability,也就是官方开始推荐广泛使用了。

(3)有关软件测试中的alpha、beta、gamma版本

广义上对测试有三个传统的称呼:alpha、beta、gamma,用来标识测试的阶段和范围。

        alpha 是指内测,即现在说的 CB,指开发团队内部测试的版本或者有限用户体验测试版本。

        beta 是指公测,即针对所有用户公开的测试版本。

&nb...

继续阅读

发表在 technologys | 标签为 , , , , , | ALPHA,BETA,GAMMA,GA,RC,LTS 常见版本/version已关闭评论

SVN 一些客户端命令选项

全局选项:

--username ARG

  指定用户名称 ARG

--password ARG

  指定密码 ARG

--no-auth-cache

  不要缓存用户认证令牌

--non-interactive

  不要交互提示

--trust-server-cert

  不提示的接受未知的证书颁发机构发行的 SSL 服务器证书(只用于选项“--non-interactive”)

--config-dir ARG

  从目录 ARG 读取用户配置文件

--config-option ARG

  以下属格式设置用户配置选项:

    FILE:SECTION:OPTION=[VALUE]

  例如:

    servers:global:http-library=serf

svn
add

  把文件以及目录的名称添加到版本控制系统。他们会在下次提交时被添加到项目仓库中去。

  svn
add path...

选项:

--auto-props

  再添加它们的时候自动设置文件的属性。

--no-auto-props

  禁用自动设置属性。

svn
blame (ann, annotate, praise)

  显示文件每行的版本以及作者信息。

  svn
blame target...

选项:

--revision,
-r rev

  如果指定的rev是单个版本,显示该版本的作者信息。如果指定的版本范围re...

继续阅读

发表在 technologys | SVN 一些客户端命令选项已关闭评论

常用加密算法

算法选择:对称加密AES,非对称加密: ECC,消息摘要: MD5,数字签名:DSA


对称加密算法(加解密密钥相同)
名称
密钥长度
运算速度
安全性
资源消耗
DES
56位
较快
3DES
112位或168位
AES
128、192、256位


非对称算法(加密密钥和解密密钥不同)
名称
成熟度
安全性(取决于密钥长度)
运算速度
资源消耗
RSA
DSA
只能用于数字签名
ECC
低(计算量小,存储空间占用小,带宽要求低)


散列算法比较
名称
安全性
速度
SHA-1
MD5


对称与非对称算法比较
名称
密钥管理
安全性
速度
对称算法
比较难,不适合互联网,一般用于内部系统
快好几个数量级(软件加解密速度至少快100倍,每秒可以加解密数M比特数据),适合大数据量的加解密处理
非对称算法
密钥容易管理
慢,适合小数据量加解密或数据签名


算法选择(从性能和安全性综合)
对称加密: AES(128位),
非对称加密: ECC(160位)或RSA(1024),
消息摘要: MD5
数字签名:DSA
轻量级:TEA、RC系列(RC4),Blowfish (不常换密钥)
速度排名(个人估测,未验证):IDEA <DES <GASTI28<GOST<AES<RC4<TEA<Blowfish  

简单的加密设计: 用密钥对原文做  异或,置换,代换,移...

继续阅读

发表在 technologys | 常用加密算法已关闭评论

Zookeeper的核心:ZAB原子消息广播协议

 点击查看原图
        ZooKeeper为高可用的一致性协调框架,自然的ZooKeeper也有着一致性算法的实现,ZooKeeper使用的是ZAB协议作为数据一致性的算法,
ZAB(ZooKeeper Atomic Broadcast )
称为:原子消息广播协议;ZAB可以说是在Paxos算法基础上进行了扩展改造而来的,ZAB协议设计了支持崩溃恢复,ZooKeeper使用单一主进程
Leader用于处理客户端所有事务请求,采用ZAB协议将服务器数状态以事务形式广播到所有Follower上;由于事务间可能存在着依赖关系,ZAB
协议保证Leader广播的变更序列被顺序的处理,:一个状态被处理那么它所依赖的状态也已经提前被处理;ZAB协议支持的崩溃恢复可以保证在
Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性;

  在ZooKeeper中
所有的事务请求都由一个主服务器也就是Leader来处理,其他服务器为Follower,Leader将客户端的事务请求转换为事务Proposal,
并且将Proposal分发给集群中其他所有的Follower,然后Leader等待Follwer反馈,当有
过半数(>=N/2+1)的Follower反馈信息后,Leader将再次向集群内F... 继续阅读

发表在 technologys | Zookeeper的核心:ZAB原子消息广播协议已关闭评论

PPTP/L2TP over PPPoE的準確MTU/MRU值

Ethernet MinSize = 512bit = 64 Byte
Ethernet MaxSize = 1518 Byte
so Ethernet IP MTU = 1518 - 18 ( 6 SRCMAC+ 6 DSTMAC+ 2 TYPE+ 4 CRC) = 1500 B
so Ethernet IP TCP MSS = 1500 - 40 ( 20 IP_HEADER + 20 TCP_HEADER) = 1460 B
so Ethernet IP UDP MTU/MRU = 1500 - 28 ( 20 IP_HEADER + 8 UDP_HEADER ) = 1472 B
so PPPoE MTU/MRU = 1500 - 8 ( 6 PPPoE_SESSION + 2 PPP_HEADER ) = 1492 B
so TCP over PPPoE MSS = 1492 ( PPPoE MTU/MRU ) - 40 ( 20 IP_HEADER + 20 TCP_HEADER) = 1452
so PPTP MTU/MRU = 1500 - 56 ( 20 IP_HEADER + 20 TCP_HEADER + 12 GRE_HEADER + 4 PPP_HEADER ) = 1444 B
so TCP over PPTP MSS = 1444 ( PPTP MTU/MRU ) -...

继续阅读

发表在 technologys | PPTP/L2TP over PPPoE的準確MTU/MRU值已关闭评论

zookeeper

场景一

有这样一个场景:
统中有大约100w的用户,每个用户平
均有3个邮箱账号,每隔5分钟,每个邮箱账需要收取100封邮件,最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力,从
多个不同的网路出口进行访问外网,计算的压力得到缓解,那么每台机器的计算压力也不会很大了。

        通过我们的讨论和以往的经验判断在这场景中可以实现并行计算,但我们还期望能对并行计算的节点进行动态的添加/删除,做到在线更新并行计算的数目并且不会影响计算单元中的其他计算节点,但是有4个问题需要解决,否则会出现一些严重的问题:

  1. 20台机器同时工作时,有一台机器down掉了,其他机器怎么进行接管计算任务,否则有些用户的业务不会被处理,造成用户服务终断。
  2. 随着用户数量增加,添加机器是可以解决计算的瓶颈,但需要重启所有计算节点,如果需要,那么将会造成整个系统的不可用。
  3. 用户数量增加或者减少,计算节点中的机器会出现有的机器资源使用率繁忙,有的却空闲,因为计算节点不知道彼此的运行负载状态。
  4. 怎么去通知每个节点彼此的负载状态,怎么保证通知每个计算节点方式的可靠性和实时性。

        先不说那么多专业名词,白话来说我们需要的是...

继续阅读

发表在 technologys | zookeeper已关闭评论

ZooKeeper 数据流动图


ZooKeeper的基本原理

ZooKeeper是以Fast Paxos算法为基础的,通过选举产生一个leader,只有leader才能提交propose,具体算法可见Fast Paxos

 

2)ZooKeeper的基本运转流程

ZooKeeper主要存在以下两个流程:

  • 选举Leader
  • 同步数据

选举Leader过程中算法有很多,但要达到的选举标准是一致的:

  • Leader要具有最高的zxid 
  • 集群中大多数的机器得到响应并follow选出的Leader

下图为ZooKeeper数据流动图,比较直观地描述了ZooKeeper是如何同步数据的:

 


点击查看原图

 

 

继续阅读

发表在 technologys | ZooKeeper 数据流动图已关闭评论