精品久久人人做人人爽综合,国产亚洲美女精品久久久,久久精品蜜芽亚洲国产AV

star — Thu, 17 Sep 2015 06:09:00 GMT

服务�?后台开发中如何生成id是每个开发者都�?x��)遇到的问题�Q�在�?sh��)商、游戏领域尤其突出�?br />如何保证生成id的唯一性、可靠性、高可用性，如何�l�织id的格式，在不同的应用场景和限制下实现方式也不��相同�?br />
我们的应用场景类似电(sh��)商，在一个订单的生命周期内，有多个逻辑需要生成各自的id�Q�还要考虑到可��L��和灉|��性，我们军_��实现一个独立的id服务�?br />首先�Q�id服务必须��h��高可用性，业务逻辑处理中创建id��p�|是不可接受的�Q�所以id服务必须分布式部�|Ԍ��有多个节点同时对外服务，一个节点失败则重试其他节点�Q�保证成功创建id�?br />在分布式�pȝ��中保证数据的一致性成本是很高的，��Z��化设计和实现�Q�每个节炚w��设计成对�{�的、独立的�Q�不需要保持数据同步�?br />其次�Q�id服务必须可靠�Q�数据不能丢失，因此数据的存储放在独立的mysql数据库中�Q��用replace方式更新数据�Q�id服务本��n记录更新日志�?br />最后，id服务必须灉|��Q�可以自定义id格式�Q�可以高效灵�zȝ��实现客户端，因此通讯协议使用json over udp方式�Q�在id服务端��用lua实现id格式的灵�z�d��义�?br />

ID规则

具体规则有lua脚本定义�Q�修改脚本后需要reload生效�Q�需要实�?个函�?/div>

min_counter : 计数器最��?/div>

max_counter : 计数器最大�?/div>

reset_seconds : 计数器重�|�周�?/div>

create_id : �Ҏ(gu��)��计数器、自定义参数和时间参数创建ID�?br /> 例如�Q?br />

function min_counter()

return 0

end

function max_counter()

return 9999

end

function reset_seconds()

return 86400

end

function create_id(counter,now,salt)

local seq = counter:generate_counter()

local new_id = string.format("%01d%02d%02d%04d",now:year()%10 ,now:month(),now:day(),seq)

return new_id

end

接口

采用udp协议�Q�数据格式�ؓ(f��)json �Q�字�D�定义：(x��)

action: ��h��c�d�� get�Q?创徏ID �Q? monitor�Q�监�?/div>

rule_name: 规则名字�Q?由服务端定义

app_name : 应用名或命名�I�间 �Q?客户端自定义�Q�rule_name和app_name一起决定生成ID的唯一�?/div>

salt : 自定义参�?�Q�可选项 �Q?/div>

seq : 自定义参敎ͼ�可选项�Q�原栯��?br /> 例如:
创徏ID��h��: {"action":"get","rule_name":"o2o","app_name":"test"}

响应�Q�{"code":0,"message":"success","data":"505140001"}

监控��h��Q�{"action":"monitor","rule_name":"o2o","app_name":"test"}

响应�Q�{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}

性能

id服务器��用c++实现�Q�性能��试做的比较��单，因�ؓ(f��)性能不是id服务的主要关注点�Q?��单以php为客��L(f��ng)��q�行��试�?br /> 4个php�q�发�q�程�Q�每个进�E�不停发�?0万个��h��Q�测试结果：(x��)

total:200000 fail:0 min:0.000214 max:0.087330 avg:0.000393

total:200000 fail:0 min:0.000215 max:0.087129 avg:0.000391

total:200000 fail:0 min:0.000221 max:0.087252 avg:0.000391

total:200000 fail:0 min:0.000218 max:0.087484 avg:0.000391
说明 min : 最��耗时(�U? max : 最大耗时(�U? avg : �q�_��耗时(�U?
服务器TPS辑ֈ��q?�?�U�时�Q��^均�g�q�在0.3毫秒�?br />
�l�过在生产环境��用，�q�行�E�_��Q�现在将整个�pȝ��开源出来，�Ƣ迎试用�Q�有��M��意见和徏议欢�q�反馈到l(f��)xyfirst�Q?63.com �?br />

��目源代码位�|?: https://github.com/lxyfirst/id_server

版本更新9.19
1.增加数据落地的预保存和批量保存机�Ӟ��一斚w��减少数据库压力，一斚w��增加异步保存的可靠性�?br />2.�׃��ȝ��E�和数据库线�E�只需要传递sql语句�Q�将�U�程间通信由pipe方式改�ؓ(f��)eventfd + lockfree queue方式�?/div>

star 2015-09-17 14:09 发表评论

star — Fri, 23 May 2014 03:03:00 GMT

svn的�̎号和权限��理是基于文件的�Q�修�Ҏ(gu��)��需要更新到服务器，多有不便�Q�可利用svn��理账号和权限，利用svn的pos-commit 钩子监测账号和权限文件变化，多个库可�׃�n同一账号和权限文件�?br />
/home/svn/conf/目录下存放了多个库共用的passwd和authz文�g�Q�用来控制这些库的�̎号和讉K��权限�Q?/span>独立的svn_admin库中存放对应的passwd和authz文�g�Q�有更新时自动同步到/home/svn/conf/下�?br />svn_admin库的post-commit 脚本如下:

REPOS="$1"
REV="$2"
FILE_DIR="/home/svn/conf"
UPDATE_FILE_LIST="passwd authz"

for FILENAME in $UPDATE_FILE_LIST ; do
    if svnlook changed $REPOS -r $REV |grep $FILENAME >/dev/null ; then
        DST_FILE=$FILE_DIR/$FILENAME
        mv $DST_FILE $DST_FILE.old
        svnlook cat $REPOS $FILENAME > $DST_FILE
    fi
done

star 2014-05-23 11:03 发表评论

star — Sun, 09 Mar 2014 05:42:00 GMT

twemproxy(nutcracker)是twitter实现的开源memcached和redis代理�Q�主要功能是�Ҏ(gu��)��key分发��h��到后端的memcached和redis服务器，��化memcached和redis集群服务的实现�?br />��Z��对twemproxy实现机制的好奇，��要阅��M��代码�Q�特别是�|�络处理部分�Q�一般这部分是网�l�服务器的核心，�q�里记录下其代码实现逻辑和发现的问题�?br />
twemproxy作�ؓ(f��)代理服务器，��M��逻辑都围�l�着数据��{�Q�采用了单线�E�非��d��模型�Q�在linux下由epoll驱动整个�E�序的运行，对于事�g驱动模块的封装在event目录下，event_base对象是引擎，conn对象是具体的�q�接�Q�conn对象中定义一�p�d��事�g处理的回调函敎ͼ�典型的reactor机制�Q�linux下的实现文�g是nc_epoll.c �?nbsp;
事�g引擎模块使用了两层回调机�Ӟ�� event_base上有个基本的回调函数�Q�这个回调函数进一步调用conn对象的相应回调函�? �Q�注�Q�一般直接��用conn的回调也��够了）�?br />面向客户端的conn回调�Q?br />

conn->recv = msg_recv;

conn->recv_next = req_recv_next;

conn->recv_done = req_recv_done;

conn->send = msg_send;

conn->send_next = rsp_send_next;

conn->send_done = rsp_send_done;

conn->close = client_close;

conn->active = client_active;

conn->enqueue_outq = req_client_enqueue_omsgq;

conn->dequeue_outq = req_client_dequeue_omsgq;

面向后端memcached和redis的conn回调�Q?/div>

conn->recv = msg_recv;

conn->recv_next = rsp_recv_next;

conn->recv_done = rsp_recv_done;

conn->send = msg_send;

conn->send_next = req_send_next;

conn->send_done = req_send_done;

conn->close = server_close;

conn->active = server_active;

conn->enqueue_inq = req_server_enqueue_imsgq;

conn->dequeue_inq = req_server_dequeue_imsgq;

conn->enqueue_outq = req_server_enqueue_omsgq;

conn->dequeue_outq = req_server_dequeue_omsgq;

twemproxy面向客户端时�Q�由proxy_accept接收�q�接�Q�创建客��L(f��ng)��conn对象�Q��ƈ��其加入��C��件引擎中�?br />twemproxy面向后端�Ӟ��由server_pool��理各个到后端的conn对象�Q�同样会(x��)加入��C��件引擎中�?br />
在请求处理模块有2个主要的概念�?mbuf对象和msg对象�Q�mbuf对象是数据缓冲区�Q�发送和接收的数据都存放在mbuf中，采用铑ּ��理。msg对象是具体的逻辑��h��Q�采用链式管理，形成��h��/响应队列。请求和响应的处理模块分别在nc_request.c和nc_response.c中实现�?br />
客户端连接的处理逻辑�Q?br />

core_recv

conn->recv 即msg_recv �Q�read事�g处理

conn->recv_next 即req_recv_next �Q�获得msg对象�Q�没有则创徏

msg_recv_chain 创徏mbuf对象�Q�接收�ƈ处理数据

[create mbuf]

conn_recv 真正的read数据

msg_parse 解析 �Q?mbuf->msg

msg_parsed 解析完成

conn->recv_done 即req_recv_done

req_filter �q��o(h��)器，暂无操作

req_forward 分发��h��

server_pool_conn �Ҏ(gu��)��key获得后端conn对象

��s_conn加入写事件监控，��msg加入转发队列�Q�可写事件被触发后�{发队列内��h��

s_conn->enqueue_inq req_server_enqueue_imsgq

conn->recv_next 即req_recv_next�Q��l�下一�?/div>
注：(x��)从代码实现看回调逻辑的层�ơ性不强，收发数据攑օ�mbuf列表�Q�然后用writev处理�Q�在遇到发送不完时�q�要拆分mbuf�Q�重新组�l�iovec�Q�实��C��有些复杂�?br />另外conn对象的数据采用一�ơ读/写完的方式处理，在高压力下可能会(x��)产生大量的mbuf对象�?br />
未完待箋�?br />

star 2014-03-09 13:42 发表评论

star — Tue, 07 Jan 2014 02:07:00 GMT

�q�期��目需要一个mysql代理服务器，实现mysql协议代理和�\由功能，形成��单的mysql集群服务。现成的开源方案是mysql-proxy �Q?分析功能和源代码后发现跟我们的应用场景不太匹配，于是军_��重新实现一个符合需求的mysql代理服务器，考虑到需要完��支持mysql协议�Q�优先选择了libdrizzle库， libdrizzle是开源项目drizzle中的协议库，而drizzle可以看作mysql的分支版本，目前�E�_��版本�?.1.36 �Q?下面主要是记录��用libdrizzle中遇到的一些问题�?br /> 1. 关于nonblock模式的问题，��C��应用服务器典型架构一般是使用reactor/proactor模式的事仉��动模型，如何把libdrizzle和应用服务器的驱动模型很好的�l�合��h��其重要�Q?nbsp;libdrizzle支持nonblock模式�Q�独立实��C��事�g驱动机制�Q��用poll监控�|�络事�g�Q�具体在drizzle_con_wait()中实玎ͼ�然后通过drizzle_con_ready()遍历产生事�g的网�l�连接，即drizzle_con_st对象�Q�该接口难以与通常的网�l�事仉��动机刉��合��用，性能也不太理惻I��具体用法可参见其自带的样例程序examples/client.cc , 也就是说libdrizzle的驱动模型需要重新封装成跟应用服务器相匹配，才能真正发挥nonblock模式的性能�?br />
2. drizzle_result_st对象初始时一些内部数据没有初始化�Q�容易造成�E�序崩溃�Q�因此需要修�Ҏ(gu��)��造函敎ͼ�初始化所有内部数据。涉�?qi��ng)文�?/font>libdrizzle-2.0/structs.h �?/font>相应字段为field, field_buffer,row �?br />

3. libdrizzle中运行时产生的内部对象都以双链表形式挂接在其上��对象中，例如drizzle_st对象中有个双链表�l�护其创建的drizzle_con_st对象�Q�类似地�Q?/font>drizzle_con_st对象中有个双链表�l�护其创建的drizzle_result_st对象�Q�所有的对象通过�q�种形式�U�联��理�Q?/font>�q�且�q�些对象中保存着上下文相关的状态，�q�样的实现方便资源管理，防止资源泄露�Q�但�?/font>代理服务�?/font>中，��h��和结果在不断转发�q�程中会(x��)形成大量的内存拷贝，��Z��减少转发�q�程中的内存拯��Q�需要把drizzle_result_st昑ּ�的从drizzle_con_st中移除，当数据发往客户端完成后再删除，因此增加�?/font>drizzle_result_detach()接口�Q�用于从drizzle_con_st对象中移�?/font>drizzle_result_st对象 �Q?nbsp;涉及(qi��ng)文�glibdrizzle-2.0/result.h , libdrizzle-2.0/result.cc �?br />

void drizzle_result_detach(drizzle_result_st *result)
{

  if (result->con)
  {
    result->con->result_count--;
    if (result->con->result_list == result)
      result->con->result_list= result->next;
  }

  if (result->prev)
    result->prev->next= result->next;

  if (result->next)
    result->next->prev= result->prev;

  result->con = NULL ;
  result->prev = NULL ;
  result->next = NULL ;
}

star 2014-01-07 10:07 发表评论

keepalived配置注意事项

star — Wed, 16 Nov 2011 03:11:00 GMT

keepalived是用来进行网�l�fail-over的强大工��P��配置��单灵�z�，功能强大�Q�实��C��vrrp协议和健��h��查，配合lvs使用可实现高可用性�?br />典型双机热备配置�Ҏ(gu��)��Q?br />两台机器的keepalived实例都配�|�成BACKUP状态，priority高的自动作�ؓ(f��)master , priority低的自动作�ؓ(f��)slave �Q�也可以��priority讄��为相同，先启动的作�ؓ(f��)master 。两辚w��讄��nopreempt�Q�防止出现故�?>恢复�q�程中的再切换�?br />1.在master发生故障->恢复�q�程中，原backup�?x��)替换��?f��)master对外服务�Q�当原master恢复后，一般希望原master作�ؓ(f��)新backup�Q�以避免master的再�ơ切换，可以使用nopreempt参数�Q�防止priority高的发�v切换�?br />2. 当keepalived讄��为随�pȝ��启动自动启动�Ӟ��应加上一定的延迟�Q�防止网�l�或�pȝ��未准备好影响keepalived的状态�?br />3. 当后端的RS有状�?https)�Ӟ��lvs一般需要��用sh负蝲��法或��用持久性连接，以便同一来源的请求分发到同一RS�Q�当http和https的请求分发需要一致时�Q�可以��用iptable�Ҏ(gu��)��文做fmark�Q��用fmark配置lvs �?br />

star 2011-11-16 11:11 发表评论

LVS配置注意事项

star — Mon, 10 Oct 2011 07:55:00 GMT

1. arp问题
在DR或者tunnel模式下，RS需要绑定VIP以便直接��报文发回客��L(f��ng)��。因此需要在RS上屏蔽网�l�内对VIP�q�行arp查询的响�?�?br />

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

2. mtu问题
在tunnel模式�?�Q�LD��客��L(f��ng)��报文�q�行��装�Q�加IPIP��_(d��)��后发送给RS �Q?因此RS需要调整MTU大小�Q�预留IPIP头空��_(d��)��以便客户端正��分包�?br />

ifconfig "$OUT_DEV" mtu 1480

3.报文转发问题
在DR或者tunnel模式下，报文直接转发到RS�?br />

echo 1 > /proc/sys/net/ipv4/ip_forward

4.LD支持�q�接数问�?br />   内核ip_vs模块的参数conn_tab_bits指定了conn表的大小�Q�最大�ؓ(f��)20 �Q�支�?M个连接�?br />
5.LD做HA时VIP接管问题
   新LD接管故障LD的VIP�Ӟ��需要及(qi��ng)时做arp�q�播�Q�keepalived�?x��)自动完成，也通过arping命��o(h��)查看�?br />
6.LD的cpu负蝲问题
   LD的网卡��Y中断(ksoftirqd)�׃��个cpu处理�Q�无法利用多核，调整软中断的smp_affinity可以改变�l�定的cpu�Q�但无法做多核负载均衡�?br /> 内核2.6.32之后已经支持软中断的负蝲均衡�?br />   使用支持RSS的网卡，有多个队列，或者��用多个网卡做bonding �?br />

echo "alias bond0 bonding" >> /etc/modprobe.conf

修改ifcfg-bond0 , ifcfg-ethX配置文�g�?br />
7. �pȝ��内核参数调整参�?br />

net.ipv4.tcp_tw_recyle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 40960
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_tw_buckets = 8192
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 40960
#net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_rmem = 4194304 8388608 16777216
net.ipv4.tcp_wmem = 4194304 8388608 16777216
net.ipv4.udp_mem = 4194304 8388608 16777216
net.ipv4.udp_rmem_min = 1048576
net.ipv4.udp_wmem_min = 1048576

net.core.somaxconn = 40960
net.core.netdev_max_backlog = 40960
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

参�?http://www.austintek.com/LVS/

star 2011-10-10 15:55 发表评论

�|�卡负蝲均衡

star — Thu, 04 Aug 2011 02:44:00 GMT

1.服务器网卡��Y中断的cpu负蝲均衡�?1.�|�卡支持RSS�Q�Receive Side Scaling�Q�接收方扩展�Q��?2.内核支持RSS�?/span>
2.�|�卡bonding 。多块网卡绑定同一IP地址对外提供服务�Q�通过bonding�Q�虚拟一块网卡对外提供服务�?div>http://t.chinaunix.net/archiver/tid-1927269.html

star 2011-08-04 10:44 发表评论

linux上mq和socketpair的通信性能比较

star — Thu, 04 Aug 2011 02:36:00 GMT

多线�E�系�l�中通知用哪�U�方式效率更好，在一�?核Xeon 3.00GHZ的机器上�Ҏ(gu��)��了linux下mq和socketpair通信性能�Q�一写线�E�，一�ȝ��E�，初步�l�论是mq胜出�Q�mq 46w/s �Q�socketpair 40w/s �?/span>

star 2011-08-04 10:36 发表评论

典型�|�络模型性能比较

star — Thu, 07 Jul 2011 05:24:00 GMT

使用几个�l�典�|�络模型实现非阻塞简�?/span>http服务�Q�部�|�在一�?/span>4�?/span>Xeon 3.00GHZ的机器上�q�行压力��试�?/span>

短连�?/span>

长连�?/span>

客户�?/span>

1个线�E?/span>

97%cpu�Q�多核分�?/span>

60%cpu�|�卡中断

1.6w/s

�q�_��响应旉��10ms

100%cpu

15%cpu�|�卡软中�?/span>

2.8w/s

�q�_��响应旉��7ms

100�q�发/客户�?/span>

100w��h��/客户�?/span>

2个客��L(f��ng)��

4个线�E?/span>

每个�U�程70%cpu

99%cpu�|�卡中断

2.1w/s

�q�_��响应旉��9ms

每个�U�程100%cpu

40%cpu�|�卡软中�?/span>

6.5w/s

�q�_��响应旉��3ms

100�q�发/客户�?/span>

100w��h��/客户�?/span>

2个客��L(f��ng)��

1�?/span>leader�U�程�Q�接受连�?/span>

4�?/span>worker�U�程�Q�处理请�?/span>

leader�U�程90%cpu

worker�U�程40%cpu

75%�|�卡中断

1.8w/s

�q�_��响应旉��10ms

leader�U�程1%cpu

worker�U�程100%cpu

40%�|�卡中断

6.0w/s

�q�_��响应旉��3ms

100�q�发/客户�?/span>

100w��h��/客户�?/span>

2个客��L(f��ng)��

�l�论�Q?/span>

1. 短连接中�Q�徏立连接是很耗费资源的�?/span>

2. 长连接中�Q�多�U�程在提高处理能力方面是很有价值的�Q�尤其是�q�算量多的请求�?/span>

3. 多个�U�程同时接受�q�接�?x��)造成cpu软中断的overhead�?/span>

star 2011-07-07 13:24 发表评论

star — Wed, 29 Jun 2011 06:43:00 GMT

beanstalkd源于fackbook�Q�是一个快速、简单的内存消息队列�Q�也可以开启binlog�Q�消息将被写入日志文�Ӟ��用于重启时恢复数据�?br />1.消息被称作job�Q�在服务器端储存在内存队列中�Q�具有DELAYED,READY,RESERVED,BURIED状态，状态�{换图如下

Here is a picture of the typical job lifecycle:

   put            reserve               delete
  -----> [READY] ---------> [RESERVED] --------> *poof*

Here is a picture with more possibilities:

   put with delay               release with delay
  ----------------> [DELAYED] <------------.
                        |                   |
                        | (time passes)     |
                        |                   |
   put                  v     reserve       |       delete
  -----------------> [READY] ---------> [RESERVED] --------> *poof*
                       ^  ^                |  |
                       |   \  release      |  |
                       |    `-------------'   |
                       |                      |
                       | kick                 |
                       |                      |
                       |       bury           |
                    [BURIED] <---------------'
                       |
                       |  delete
                        `--------> *poof*

消息支持优先�U�，生存旉��的设�|�。不同状态的消息分别处于相应状态的队列中�?br />2. 消息属于某个tube�Q�tube�c�M��于namespace或者消息主题的概念�Q�消费者可以订阅一个或多个tube �Q�从而接收这些tube的消�?�?br />3. beanstalkd的代码实现和协议定义很类似memcached的风根{�?br />

star 2011-06-29 14:43 发表评论