Recently in Tech Category

--EOF--

--EOF--

--EOF--

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

找到这个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--

Protocol Buffers: Google's Data Interchange Format

Protocol Buffers

大概看了一下介绍：

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

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

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

4.比xml小很多

5.操作更方便

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

--EOF--

互斥锁：

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

重点：

{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-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--

如何理解这些名词，如何使用它们？

--EOF--