Recently in Tech Category

OpenSSL API 相关教程参考

| No Comments
使用 OpenSSL API 进行安全编程,第 1 部分: 创建基本的安全连接和非安全连接

使用 OpenSSL API 进行安全编程,第 2 部分: 安全握手

使用 OpenSSL API 进行安全编程,第 3 部分: 提供安全服务

--EOF--

出门,请忘记它~

| No Comments
昨天在广州招聘的酒店就看到了水木社区有人在问大讲堂的一些资料下载,心里就纳闷了,难道有内鬼?
下午果然就有人贴地址了,再到今天,火了。看时间,都是2009年3月copy打包的,而且是源文件,看来是离开公司的人?

前几天和一个同事在去广州招聘的路上聊天,他就告诉我他现在的部门很多信息都非常保密,我问了一些业务情况,都说是不能说的。就算在他们内部,有时候虽然可以打听,但都是出了门就请忘记的,这也难怪了这个部门一直很低调的不在公司抛头露面,毕竟有些东西是不方便拿出来说的。

想来自己的笔记本上也有大把这样的数据,一直都是很小心的,以后要更小心了,不然再弄出一个啥门来,对自己,对东家,都非常不好,因为你永远不知道这些东西泄漏出去对公司会有多大的伤害!

再想起来听tony的为数不多的几个讲座,ppt都是超级简单,真可谓大道至简,大大的标题,大大的字,句句中的:
0和1的思维=60分;
可伸缩,可调度;
电力告急;专线告急;
招行的深圳、上海的IDC大楼;

要知道,上面很多东西是2008年上半年已经搞定!!!
所以,出门,请忘记它。

--EOF--

数字的魅力

| No Comments
一些数字-2009:
1.BU服务器数量:1.5w台,90在SZ,公司超过5w在SZ
2.设备成本:6500w
3.带宽成本:8000w
4.带宽占用近200G,接近SZ极限
5.4300条告警
6.上联,下联,双路,核心交换机
7.城域网:20G环路互备
8.2.5G城际光纤
9.中国联通到香港国际出口中国电信到香港的国际出口都7.xG,但网通用户只有电信一半,因此。。。我家里网通的路线访问香港网站速度不错是有原因的,到美国的国际出口这两者就差的大了
10.进程时间片:10ms-200ms?


--EOF--

系统技术分享 2010.04.02

| No Comments
1.承认现实,公司网络现状以及国内网络现状
2.漏洞是怎么产生的?安全的函数?安全的服务?
3.监控各个层次
4.魔鬼就在细节中:gettimeofday解析->>mmx
5.反传统,Say No;细节;现在优化的是一个圈,圈外还是更无限的待优化的

--EOF--

http://beerpla.net/2008/09/05/mysql-slave-delay-explained-and-7-ways-to-battle-it/

1)常态化数据,减少数据的变更,减少IO

2)shard:数据分块,用不同的表,不同的slave?

3)升级机器性能

4)应用程序部署在不同的机器上,避免互相影响

5)4的另外一直实现 -- 不同的MySQL实例,前提就是机器足够强

6)优化sql,将长时间执行的分片执行

7)对slave的负载做监控,做到负载均衡,不要将全部查询压到一台slave去。

 

另外的注意点:

slave不是万能的,slave只能分担读的压力,写的压力一点没少,如果系统的瓶颈由读变为写的时候,slave就失去了效用,此时再多的slave也没用,真正需要的是解决master的写能力的问题了。

 

 

--EOF--

Google的可扩展性

| No Comments

找到这个slide :

Handling Large Datasets at Google Current Systems and Future Directions.pdf

是Goolge的大牛:Jeff Dean 的一个slide,大概讲了Google 后台整个系统的一些大的框架:

- Scheduling system
- GFS
- BigTable
- MapReduce

其实每个模块Google都已经发了Paper了,直接到 Google Research  下载即可。

 

下一代Google的架构会如何呢?

--EOF--

Google的内部数据交换格式

| No Comments

Protocol Buffers: Google's Data Interchange Format

Protocol Buffers

大概看了一下介绍:

1.各种语言的开发包都有

2.协议到文件或者说到buffer非常方便,反之也是

3.基本的语义或者说xml需要表现的文本方面的优势它也具备

4.比xml小很多

5.操作更方便

6.一个协议一个类?感觉更OO

 

--EOF--

sem信号量的2个小用法

| No Comments

互斥锁:

保证某个进程只能启动一次之类的:

重点:

{sem_index, 0, IPC_NOWAIT}

期待信号量为0,如果不是,立即返回错误!


int sem_v_lock_mutex(int sem_id, int sem_index)
{
 struct sembuf sops[2] = {{sem_index, 0, IPC_NOWAIT}, {sem_index, 1, SEM_UNDO}};
 size_t nsops = 2;
 
 assert(sem_id>=0);
 printf("[%s:] sem_index:%d v + 1 \n\n", __func__, sem_index);
 if (semop(sem_id, &sops[0], nsops ) == -1 ){
  perror("v+1 error, haved v+1 [mutex locked]");
  return -1;
 }
  
 return 0;  
}

 

资源锁:

int sem_v(int sem_id, sem_index)
{
    struct sembuf sops[2] = {{sem_index, 0, SEM_UNDO}, {sem_index, 1, SEM_UNDO}};
    size_t nsops = 2;

    assert(sem_id>=0);
    if (semop(sem_id, &sops[0], nsops ) == -1 ){
        perror("v+1 error, haved v+1 [mutex locked]");
        return -1;
    }

    return 0;
}

int sem_p(int sem_id, sem_index)
{
    struct sembuf sops[1] = {{sem_index, -1, SEM_UNDO}};
    size_t nsops = 1;

    assert(sem_id>=0);
    if (semop(sem_id, &sops[0], nsops ) == -1 )
        return -1;

    return 0;
}

每次访问资源时,先sev_v  再 sev_p

这里的PV操作和信号量总觉得有点绕?

上面的实现个人觉得会比较简单:每次操作期待信号量值为0 -- 标识现在有0个进程正在使用某个资源,每个进程只有在无人访问的时候才可以去访问这个资源,这样就互斥访问了。

这里信号量的初始值为0.

 

如果信号量的初始值为1,则就可以完全对应使用pv操作了:

sem_p:

struct sembuf sops[1] = {{sem_index, -1, SEM_UNDO}, {sem_index, 0, SEM_UNDO}};

sem_v:

struct sembuf sops[1] = {{sem_index, 1, SEM_UNDO}};

 

这样调用的顺序就可以是:

sem_p

function()

sem_v

 

 

--EOF--

ebay的系统扩展性经验

| No Comments

昨天看了 ebay-scalability-best-practices ,做了简单的摘要记录:

可扩展的衡量:性价比


Best Practice #1: Partition by Function
Further, the more decoupled that unrelated functionality can be, the more flexibility you will have to scale them independently of one another.
代码层,应用层,数据库层都需要进行功能分割,好处:可以独立的扩展

Best Practice #2: Split Horizontally
垂直分割?
减少耦合后,任何一个单个模块可以搞定自己的系统,不依赖其他
无状态的应用服务器,没有事务,任意扩展--scale out
数据库:肯定是有状态的  shard 简单的取模分割,扩展  取模的key可以是很多

Best Practice #3: Avoid Distributed Transactions
The CAP theorem, postulated almost 10 years ago by Inktomi's Eric Brewer, states that of three highly desirable properties of distributed systems - consistency (C), availability (A), and partition-tolerance (P) - you can only choose two at any one time. For a high-traffic web site, we have to choose partition-tolerance, since it is fundamental to scaling. For a 24x7 web site, we typically choose availability. So immediate consistency has to give way.
避免分布式事务,用另外的方法尽量保证一致性

Best Practice #4: Decouple Functions Asynchronously
Techniques like SEDA (Staged Event-Driven Architecture) can be used for asynchrony inside an individual component while retaining an easy-to-understand programming model. Between components, the principle is the same -- avoid synchronous coupling as much as possible.
异步解耦,减少系统间的耦合

Best Practice #5: Move Processing To Asynchronous Flows
异步处理

Best Practice #6: Virtualize At All Levels
对上层调用者屏蔽实现细节 O-R LVS-balance都是属于这种

Best Practice #7: Cache Appropriately
避免cache滥用,造成系统对cache 可用性的依赖,影响系统的可靠性。

--EOF--

DO PO BO AO AO DAO CAO

| No Comments

如何理解这些名词,如何使用它们?

--EOF--

Pages

May 2016

Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

About this Archive

This page is an archive of recent entries in the Tech category.

MySQL is the previous category.

WebHosting is the next category.

Find recent content on the main index or look in the archives to find all content.