分类
设计创意
办公创意
游客您好
第三方账号登陆
  • 点击联系客服

    在线时间:8:00-16:00

    客服电话

    153-9695-9698

    电子邮件

    84840@163.com
  • 搜酷APP

    随时掌握行业动态

  • 扫描二维码

    关注搜酷微信公众号

Redis偶发连接失败案例实战记录
[复制链接]
2019 - 09 - 06 发布
未知地区 | 未知职业
nidaye123 发表于 2019-9-6 09:54:48 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
        前言
        本文主要给大家介绍了关于Redis偶发连接失败的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧
        【作者】
        张延俊:携程技术保障中心资深DBA,对数据库架构和疑难问题分析排查有浓厚的兴趣。
        寿向晨:携程技术保障中心高级DBA,主要负责携程Redis及DB的运维工作,在自动化运维,流程化及监控排障等方面有较多的实践经验,喜欢深入分析问题,提高团队运维效率。
        【问题描述】
        ?生产环境有一个Redis会偶尔发生连接失败的报错,报错的时间点、客户端IP并没有特别明显的规律,过一会儿,报错会自动恢复。
        ?以下是客户端报错信息:
        CRedis.Client.RExceptions.ExcuteCommandException: Unable to Connect redis server: ---> CRedis.Third.Redis.RedisException: Unable to Connect redis server: 在 CRedis.Third.Redis.RedisNativeClient.CreateConnectionError() 在 CRedis.Third.Redis.RedisNativeClient.SendExpectData(Byte[][] cmdWithBinaryArgs) 在 CRedis.Client.Entities.RedisServer.c__DisplayClassd`1.
        ?从报错的信息来看,应该是连接不上Redis所致。Redis的版本是2.8.19。虽然版本有点老,但基本运行稳定。
        ?线上环境只有这个集群有偶尔报错。这个集群的一个比较明显的特征是客户端服务器比较多,有上百台。
        【问题分析】
        ?从报错的信息来看,客户端连接不到服务端。常见的原因有以下几点:
           
  •         一个常见的原因是由于端口耗尽,对网络连接进行排查,在出问题的点上,TCP连接数远没有达到端口耗尽的场景,因此这个不是Redis连接不上的根本原因。       
  •         另外一种常见的场景是在服务端有慢查询,导致Redis服务阻塞。我们在Redis服务端,把运行超过10毫秒的语句进行抓取,也没有抓到运行慢的语句。
        ?从服务端的部署的监控来看,出问题的点上,连接数有一个突然飙升,从3500个连接突然飙升至4100个连接。如下图显示:
       
        同时间,服务器端显示Redis服务端有丢包现象:345539 – 344683 = 856个包。
        Sat Apr 7 10:41:40 CST 2018 1699 outgoing packets dropped 92 dropped because of missing route 344683 SYNs to LISTEN sockets dropped 344683 times the listen queue of a socket overflowed
        Sat Apr 7 10:41:41 CST 2018 1699 outgoing packets dropped 92 dropped because of missing route 345539 SYNs to LISTEN sockets dropped 345539 times the listen queue of a socket overflowed
        ?客户端报错的原因基本确定,是因为建连速度太快,导致服务端backlog队列溢出,连接被server端reset。
        【关于backlog overflow】
        ?在高并发的短连接服务中,这是一种很常见的tcp报错类型。一个正常的tcp建连过程如下:
        ?1.client发送一个(SYN)给server
        ?2.server返回一个(SYN,ACK)给client
        ?3.client返回一个(ACK)
        ?三次握手结束,对client来说建连成功,client可以继续发送数据包给server,但是这个时候server端未必ready,如下图所示 :
       
        在BSD版本内核实现的tcp协议中,server端建连过程需要两个队列,一个是SYN queue,一个是accept queue。前者叫半开连接(或者半连接)队列,在接收到client发送的SYN时加入队列。(一种常见的网络攻击方式就是不断发送SYN但是不发送ACK从而导致server端的半开队列撑爆,server端拒绝服务。)后者叫全连接队列,server返回(SYN,ACK),在接收到client发送ACK后(此时client会认为建连已经完成,会开始发送PSH包),如果accept queue没有满,那么server从SYN queue把连接信息移到accept queue;如果此时accept queue溢出的话,server的行为要看配置。如果tcp_abort_on_overflow为0(默认),那么直接drop掉client发送的PSH包,此时client会进入重发过程,一段时间后server端重新发送SYN,ACK,重新从建连的第二步开始;如果tcp_abort_on_overflow为1,那么server端发现accept queue满之后直接发送reset。
        通过wireshark搜索发现在一秒内有超过2000次对Redis Server端发起建连请求。我们尝试修改tcp backlog大小,从511调整到2048, 问题并没有得到解决。所以此类微调,并不能彻底的解决问题。
        【网络包分析】
        我们用wireshark来识别网络拥塞的准确时间点和原因。我们已经有了准确的报错时间点,先用editcap把超大的tcp包裁剪一下,裁成30秒间隔,并通过wireshark I/O 100ms间隔分析网络阻塞的准确时间点:
       
        ?根据图标可以明显看到tcp的packets来往存在block。
        ?对该block前后的网络包进行明细分析,网络包来往情况如下:

                Time                Source                Dest                description                                                ??12:01:54.6536050??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…AP…                                ??12:01:54.6538580??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…AP…                                ??12:01:54.6539770??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…AP…                                ??12:01:54.6720580??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…A..S..                                ??12:01:54.6727200??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…A……                                ??12:01:54.6808480??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…AP…..                                ??12:01:54.6910840??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…A…S.,                                ??12:01:54.6911950??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…A……                                ??… ??                ??… ??                ?? … ??                ?? …                                ??12:01:56.1181350??                ??Redis-Server??                ??Clients??                ??TCP:Flags=…AP….       
        12:01:54.6808480, Redis Server端向客户端发送了一个Push包,也就是对于查询请求的一个结果返回。后面的包都是在做连接处理,包括Ack包,Ack确认包,以及重置的RST包,紧接着下面一个Push包是在12:01:56.1181350发出的。中间的间隔是1.4372870秒。也就是说,在这1.4372870秒期间,Redis的服务器端,除了做一个查询,其他的操作都是在做建连,或拒绝连接。
        客户端报错的前后逻辑已经清楚了,redis-server卡了1.43秒,client的connection pool被打满,疯狂新建连接,server的accept queue满,直接拒绝服务,client报错。开始怀疑client发送了特殊命令,这时需要确认一下client的最后几个命令是什么,找到redis-server卡死前的第一个包,装一个wireshark的redis插件,看到最后几个命令是简单的get,并且key-value都很小,不至于需要耗费1.43秒才能完成。服务端也没有slow log,此时排障再次陷入僵局。
        【进一步分析】
        为了了解这1.43秒之内,Redis Server在做什么事情,我们用pstack来抓取信息。Pstack本质上是gdb attach. 高频率的抓取会影响redis的吞吐。死循环0.5秒一次无脑抓,在redis-server卡死的时候抓到堆栈如下(过滤了没用的栈信息):
                Thu May 31 11:29:18 CST 2018
        Thread 1 (Thread 0x7ff2db6de720 (LWP 8378)):
        #0 0x000000000048cec4 in ?? ()
        #1 0x00000000004914a4 in je_arena_ralloc ()
        #2 0x00000000004836a1 in je_realloc ()
        #3 0x0000000000422cc5 in zrealloc ()
        #4 0x00000000004213d7 in sdsRemoveFreeSpace ()
        #5 0x000000000041ef3c in clientsCronResizeQueryBuffer ()
        #6 0x00000000004205de in clientsCron ()
        #7 0x0000000000420784 in serverCron ()
        #8 0x0000000000418542 in aeProcessEvents ()
        #9 0x000000000041873b in aeMAIn ()
        #10 0x0000000000420fce in main ()
        Thu May 31 11:29:19 CST 2018
        Thread 1 (Thread 0x7ff2db6de720 (LWP 8378)):
        #0 0x0000003729ee5407 in madvise () from /lib64/libc.so.6
        #1 0x0000000000493a4e in je_pages_purge ()
        #2 0x000000000048cf70 in ?? ()
        #3 0x00000000004914a4 in je_arena_ralloc ()
        #4 0x00000000004836a1 in je_realloc ()
        #5 0x0000000000422cc5 in zrealloc ()
        #6 0x00000000004213d7 in sdsRemoveFreeSpace ()
        #7 0x000000000041ef3c in clientsCronResizeQueryBuffer ()
        #8 0x00000000004205de in clientsCron ()
        #9 0x0000000000420784 in serverCron ()
        #10 0x0000000000418542 in aeProcessEvents ()
        #11 0x000000000041873b in aeMain ()
        #12 0x0000000000420fce in main ()
        Thu May 31 11:29:19 CST 2018
        Thread 1 (Thread 0x7ff2db6de720 (LWP 8378)):
        #0 0x000000000048108c in je_malloc_usable_size ()
        #1 0x0000000000422be6 in zmalloc ()
        #2 0x00000000004220bc in sdsnewlen ()
        #3 0x000000000042c409 in createStringObject ()
        #4 0x000000000042918e in processMultibulkBuffer ()
        #5 0x0000000000429662 in processInputBuffer ()
        #6 0x0000000000429762 in readQueryFromClient ()
        #7 0x000000000041847c in aeProcessEvents ()
        #8 0x000000000041873b in aeMain ()
        #9 0x0000000000420fce in main ()
        Thu May 31 11:29:20 CST 2018
        Thread 1 (Thread 0x7ff2db6de720 (LWP 8378)):
        #0 0x000000372a60e7cd in write () from /lib64/libpthread.so.0
        #1 0x0000000000428833 in sendReplyToClient ()
        #2 0x0000000000418435 in aeProcessEvents ()
        #3 0x000000000041873b in aeMain ()
        #4 0x0000000000420fce in main ()

        重复多次抓取后,从堆栈中发现可疑堆栈clientsCronResizeQueryBuffer位置,属于serverCron()函数下,这个redis-server内部的定时调度,并不在用户线程下,这个解释了为什么卡死的时候没有出现慢查询。
        查看redis源码,确认到底redis-server在做什么:
        clientsCron(server.h):#define CLIENTS_CRON_MIN_ITERATIONS 5void clientsCron(void) { /* Make sure to process at least numclients/server.hz of clients * per call. Since this function is called server.hz times per second * we are sure that in the worst case we process all the clients in 1 * second. */ int numclients = listLength(server.clients); int iterations = numclients/server.hz; mstime_t now = mstime(); /* Process at least a few clients while we are at it, even if we need * to process less than CLIENTS_CRON_MIN_ITERATIONS to meet our contract * of processing each client once per second. */ if (iterations < CLIENTS_CRON_MIN_ITERATIONS) iterations = (numclients < CLIENTS_CRON_MIN_ITERATIONS) ? numclients : CLIENTS_CRON_MIN_ITERATIONS; while(listLength(server.clients) && iterations--) { client *c; listNode *head; /* Rotate the list, take the current head, process. * This way if the client must be removed from the list it's the * first element and we don't incur into O(N) computation. */ listRotate(server.clients); head = listFirst(server.clients); c = listNodeValue(head); /* The following functions do different service checks on the client. * The protocol is that they return non-zero if the client was * terminated. */ if (clientsCronHandleTimeout(c,now)) continue; if (clientsCronResizeQueryBuffer(c)) continue; }}
        clientsCron首先判断当前client的数量,用于控制一次清理连接的数量,生产服务器单实例的连接数量在5000不到,也就是一次清理的连接数是50个。
        clientsCronResizeQueryBuffer(server.h):/* The client query buffer is an sds.c string that can end with a lot of * free space not used, this function reclaims space if needed. * * The function always returns 0 as it never terminates the client. */int clientsCronResizeQueryBuffer(client *c) { size_t querybuf_size = sdsAllocSize(c->querybuf); time_t idletime = server.unixtime - c->lastinteraction; /* 只在以下两种情况下会Resize query buffer: * 1) Query buffer > BIG_ARG(在server.h 中定义#define PROTO_MBULK_BIG_ARG (1024*32)) 且这个Buffer的小于一段时间的客户端使用的峰值. * 2) 客户端空闲超过2s且Buffer size大于1k. */ if (((querybuf_size > PROTO_MBULK_BIG_ARG) && (querybuf_size/(c->querybuf_peak+1)) > 2) || (querybuf_size > 1024 && idletime > 2)) { /* Only resize the query buffer if it is actually wasting space. */ if (sdsavail(c->querybuf) > 1024) { c->querybuf = sdsRemoveFreeSpace(c->querybuf); } } /* Reset the peak again to capture the peak memory usage in the next * cycle. */ c->querybuf_peak = 0; return 0;}
        如果redisClient对象的query buffer满足条件,那么就直接resize掉。满足条件的连接分成两种,一种是真的很大的,比该客户端一段时间内使用的峰值还大;还有一种是很闲(idle>2)的,这两种都要满足一个条件,就是buffer free的部分超过1k。那么redis-server卡住的原因就是正好有那么50个很大的或者空闲的并且free size超过了1k大小连接的同时循环做了resize,由于redis都属于单线程工作的程序,所以block了client。那么解决这个问题办法就很明朗了,让resize 的频率变低或者resize的执行速度变快。
        既然问题出在query buffer上,我们先看一下这个东西被修改的位置:
        readQueryFromClient(networking.c):redisClient *createClient(int fd) { redisClient *c = zmalloc(sizeof(redisClient)); /* passing -1 as fd it is possible to create a non connected client. * This is useful since all the Redis commands needs to be executed * in the context of a client. When commands are executed in other * contexts (for instance a Lua script) we need a non connected client. */ if (fd != -1) { anetNonBlock(NULL,fd); anetEnableTcpNoDelay(NULL,fd); if (server.tcpkeepalive) anetKeepAlive(NULL,fd,server.tcpkeepalive); if (aeCreateFileEvent(server.el,fd,AE_READABLE, readQueryFromClient, c) == AE_ERR) { close(fd); zfree(c); return NULL; } } selectDb(c,0); c->id = server.next_client_id++; c->fd = fd; c->name = NULL; c->bufpos = 0; c->querybuf = sdsempty(); 初始化是0readQueryFromClient(networking.c):void readQueryFromClient(aeEventLoop *el, int fd, void *privdata, int mask) { redisClient *c = (redisClient*) privdata; int nread, readlen; size_t qblen; REDIS_NOTUSED(el); REDIS_NOTUSED(mask); server.current_client = c; readlen = REDIS_IOBUF_LEN; /* If this is a multi bulk request, and we are processing a bulk reply * that is large enough, try to maximize the probability that the query * buffer contains exactly the SDS string representing the object, even * at the risk of requiring more read(2) calls. This way the function * processMultiBulkBuffer() can avoid copying buffers to create the * Redis Object representing the argument. */ if (c->reqtype == REDIS_REQ_MULTIBULK && c->multibulklen && c->bulklen != -1 && c->bulklen >= REDIS_MBULK_BIG_ARG) { int remaining = (unsigned)(c->bulklen+2)-sdslen(c->querybuf); if (remaining < readlen) readlen = remaining; } qblen = sdslen(c->querybuf); if (c->querybuf_peak < qblen) c->querybuf_peak = qblen; c->querybuf = sdsMakeRoomFor(c->querybuf, readlen); 在这里会被扩大
        由此可见c->querybuf在连接第一次读取命令后的大小就会被分配至少1024*32,所以回过头再去看resize的清理逻辑就明显存在问题,每个被使用到的query buffer的大小至少就是1024*32,但是清理的时候判断条件是>1024,也就是说,所有的idle>2的被使用过的连接都会被resize掉,下次接收到请求的时候再重新分配到1024*32,这个其实是没有必要的,在访问比较频繁的群集,内存会被频繁得回收重分配,所以我们尝试将清理的判断条件改造为如下,就可以避免大部分没有必要的resize操作:
        if (((querybuf_size > REDIS_MBULK_BIG_ARG) && (querybuf_size/(c->querybuf_peak+1)) > 2) || (querybuf_size > 1024*32 && idletime > 2)) { /* Only resize the query buffer if it is actually wasting space. */ if (sdsavail(c->querybuf) > 1024*32) { c->querybuf = sdsRemoveFreeSpace(c->querybuf); } }
        这个改造的副作用是内存的开销,按照一个实例5k连接计算,5000*1024*32=160M,这点内存消耗对于上百G内存的服务器完全可以接受。
        【问题重现】
        在使用修改过源码的Redis server后,问题仍然重现了,客户端还是会报同类型的错误,且报错的时候,服务器内存依然会出现抖动。抓取内存堆栈信息如下:
                Thu Jun 14 21:56:54 CST 2018
        #3 0x0000003729ee893d in clone () from /lib64/libc.so.6
        Thread 1 (Thread 0x7f2dc108d720 (LWP 27851)):
        #0 0x0000003729ee5400 in madvise () from /lib64/libc.so.6
        #1 0x0000000000493a1e in je_pages_purge ()
        #2 0x000000000048cf40 in arena_purge ()
        #3 0x00000000004a7dad in je_tcache_bin_flush_large ()
        #4 0x00000000004a85e9 in je_tcache_event_hard ()
        #5 0x000000000042c0b5 in decrRefCount ()
        #6 0x000000000042744d in resetClient ()
        #7 0x000000000042963b in processInputBuffer ()
        #8 0x0000000000429762 in readQueryFromClient ()
        #9 0x000000000041847c in aeProcessEvents ()
        #10 0x000000000041873b in aeMain ()
        #11 0x0000000000420fce in main ()
        Thu Jun 14 21:56:54 CST 2018
        Thread 1 (Thread 0x7f2dc108d720 (LWP 27851)):
        #0 0x0000003729ee5400 in madvise () from /lib64/libc.so.6
        #1 0x0000000000493a1e in je_pages_purge ()
        #2 0x000000000048cf40 in arena_purge ()
        #3 0x00000000004a7dad in je_tcache_bin_flush_large ()
        #4 0x00000000004a85e9 in je_tcache_event_hard ()
        #5 0x000000000042c0b5 in decrRefCount ()
        #6 0x000000000042744d in resetClient ()
        #7 0x000000000042963b in processInputBuffer ()
        #8 0x0000000000429762 in readQueryFromClient ()
        #9 0x000000000041847c in aeProcessEvents ()
        #10 0x000000000041873b in aeMain ()
        #11 0x0000000000420fce in main ()

        显然,Querybuffer被频繁resize的问题已经得到了优化,但是还是会出现客户端报错。这就又陷入了僵局。难道还有其他因素导致query buffer resize变慢?我们再次抓取pstack。但这时,jemalloc引起了我们的注意。此时回想Redis的内存分配机制,Redis为避免libc内存不被释放导致大量内存碎片的问题,默认使用的是jemalloc用作内存分配管理,这次报错的堆栈信息中都是je_pages_purge () redis在调用jemalloc回收脏页。我们看下jemalloc做了些什么:
        arena_purge(arena.c)static voidarena_purge(arena_t *arena, bool all){ arena_chunk_t *chunk; size_t npurgatory; if (config_debug) { size_t ndirty = 0; arena_chunk_dirty_iter(&arena->chunks_dirty, NULL, chunks_dirty_iter_cb, (void *)&ndirty); assert(ndirty == arena->ndirty); } assert(arena->ndirty > arena->npurgatory || all); assert((arena->nactive >> opt_lg_dirty_mult) < (arena->ndirty - arena->npurgatory) || all); if (config_stats) arena->stats.npurge++; npurgatory = arena_compute_npurgatory(arena, all); arena->npurgatory += npurgatory; while (npurgatory > 0) { size_t npurgeable, npurged, nunpurged; /* Get next chunk with dirty pages. */ chunk = arena_chunk_dirty_first(&arena->chunks_dirty); if (chunk == NULL) { arena->npurgatory -= npurgatory; return; } npurgeable = chunk->ndirty; assert(npurgeable != 0); if (npurgeable > npurgatory && chunk->nruns_adjac == 0) { arena->npurgatory += npurgeable - npurgatory; npurgatory = npurgeable; } arena->npurgatory -= npurgeable; npurgatory -= npurgeable; npurged = arena_chunk_purge(arena, chunk, all); nunpurged = npurgeable - npurged; arena->npurgatory += nunpurged; npurgatory += nunpurged; }}
        Jemalloc每次回收都会判断所有实际应该清理的chunck并对清理做count,这个操作对于高响应要求的系统是很奢侈的,所以我们考虑通过升级jemalloc的版本来优化purge的性能。Redis 4.0版本发布后,性能有很大的改进,并可以通过命令回收内存,我们线上也正准备进行升级,跟随4.0发布的jemalloc版本为4.1,jemalloc的版本使用的在jemalloc的4.0之后版本的arena_purge()做了很多优化,去掉了计数器的调用,简化了很多判断逻辑,增加了arena_stash_dirty()方法合并了之前的计算和判断逻辑,增加了purge_runs_sentinel,用保持脏块在每个arena LRU中的方式替代之前的保持脏块在arena树的dirty-run-containing chunck中的方式,大幅度减少了脏块purge的体积,并且在内存回收过程中不再移动内存块。代码如下:
        arena_purge(arena.c)static voidarena_purge(arena_t *arena, bool all){ chunk_hooks_t chunk_hooks = chunk_hooks_get(arena); size_t npurge, npurgeable, npurged; arena_runs_dirty_link_t purge_runs_sentinel; extent_node_t purge_chunks_sentinel; arena->purging = true; /* * Calls to arena_dirty_count() are disabled even for debug builds * because overhead grows nonlinearly as memory usage increases. */ if (false && config_debug) { size_t ndirty = arena_dirty_count(arena); assert(ndirty == arena->ndirty); } assert((arena->nactive >> arena->lg_dirty_mult) < arena->ndirty || all); if (config_stats) arena->stats.npurge++; npurge = arena_compute_npurge(arena, all); qr_new(&purge_runs_sentinel, rd_link); extent_node_dirty_linkage_init(&purge_chunks_sentinel); npurgeable = arena_stash_dirty(arena, &chunk_hooks, all, npurge, &purge_runs_sentinel, &purge_chunks_sentinel); assert(npurgeable >= npurge); npurged = arena_purge_stashed(arena, &chunk_hooks, &purge_runs_sentinel, &purge_chunks_sentinel); assert(npurged == npurgeable); arena_unstash_purged(arena, &chunk_hooks, &purge_runs_sentinel, &purge_chunks_sentinel); arena->purging = false;}
        【解决问题】
        实际上我们有多个选项。可以使用Google的tcmalloc来代替jemalloc,可以升级jemalloc的版本等等。我们根据上面的分析,尝试通过升级jemalloc版本,实际操作为升级Redis版本来解决。我们将Redis的版本升级到4.0.9之后观察,线上客户端连接超时这个棘手的问题得到了解决。
        【问题总结】
        Redis在生产环境中因其支持高并发,响应快,易操作被广泛使用,对于运维人员而言,其响应时间的要求带来了各种各样的问题,Redis的连接超时问题是其中比较典型的一种,从发现问题,客户端连接超时,到通过抓取客户端与服务端的网络包,内存堆栈定位问题,也被其中一些假象所迷惑,最终通过升级jemalloc(Redis)的版本解决问题,这次最值得总结和借鉴的是整个分析的思路。
        总结
        以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对ASPKU源码库的支持。

注:相关教程知识阅读请移步到Redis频道。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

精彩评论2

励志类的文章 发表于 2019-10-24 20:58:20 | 显示全部楼层
励志类的文章红磨坊婚纱摄影
回复

使用道具 举报

摩登城市外挂 发表于 2019-11-10 14:10:13 | 显示全部楼层
摩登城市外挂女装淘宝代理
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

热门下载分类
  • HTML模板
  • 免抠图元素
  • PPT模板
  • 平面设计素材
  • 电商淘宝素材
  • 高清背景图
关注我们
  • 官方微信公众号
  • APP应用下载
客服咨询
  • 153-9695-9698(工作日:9:00-16:00)
  • 87382376@qq.com

所有资源均是网上搜集或网友上传提供,任何涉及商业盈利目的均不得使用,否则产生的一切后果将由您自己承担。如有侵犯您的版权,请及时发邮件联系我们

Powered by 搜酷  © 2001-2021 搜酷-搜你所想! ( 苏ICP备08105188号 )

.net网站源码,1.76传奇客户端,1.76精品服务端,1.76客户端,1.76客户端下载,11g101-2,22美女网,35dir,35分类目录,360源,3d格斗网游,404源码社区,4567tv电影网,5.20表白,52酷播,55团购网,777淘宝导购网,77作文网,92gan,92jh,92美女,adobe photoshop 7.0 中文版,aijia,arm嵌入式开发板,b2bcms,b2c商城大全,baixiu,bbs猴岛,bt仓库,bt种子发布共享系统,bt种子发布系统,bt资源下载站,catia v5教程,catia入门视频教程,catia视频教程下载,cf彩虹,cms源码,cpa交友,cpa交友广告联盟,cpa交友联盟,crm免费版,dedecms 模板,dedecms采集,dedecms自动采集,dede模板,dede模板下载,dede源码,dede整站源码,discuz 模板,discuz风格,discuz论坛模板,discuz门户模板,discuz免费模板,discuz模板,discuz模板下载,discuz商业插件,dk2私服,dnf单机版秘籍,dnf外挂制作教程,dz插件,dz模板,eblog,ecshop模板,es文件浏览器官网,flash 源码,flash源代码,flash源码,gps车辆管理,h5邪恶游戏论坛,ige引擎,kan3,luna私服,maxcms,mkz军魂,mtv下载器,p2p网站,pdfelement,phpweb破解,php云人才系统,protel99se视频教程,proteus教程,proteus下载,qirewang,qqhot,qqnc,qq分享乐园,qq挂级,qq极品乐园,qq交易论坛,qq空间psd,qq空间psd源码,qq空间资源,qq模版,qq农场游戏,qq西游私服,qq象棋外挂,qq音速小游戏,q版3d网游,q版回合制网页游戏,q版回合制网游,q版网络游戏,q堂,ro仙境传说单机版,sf online,sf登陆器,shopex模板,smarty下载,stm32视频教程,u 影,ultraedit破解版,url转向,UU资源网,u影视,u影音,v5威客网,vip源码,v宝网,v商,wap程序,wap小说,wap小说网,wap小说网站,web幻想,web游戏源码,wincc教程,wow 3.35,wp商城,wp中文网,x站源码,yicms,yiyi.cc,zanblog,z奇兵,爱客电影,爱客影视,爱漫画网站,爱装网,安卓壁纸网,安卓内存卡清理,安卓网络电视,暗黑世界网页游戏,傲世千雄,傲视千雄,傲视千雄吧,傲视千雄官网,傲视千雄金币变态服,傲视千雄私服,八卦新闻网,霸王大陆sf,霸王大陆私服,白狐 影音,白狐影视,白小姐高级会员版,百度豆丁文档下载器,百度码,百度文档下载器,百度源,百度云盘资源分享吧,百度云资源分享链接群组,百炼成仙网页游戏,包你说,宝德棋牌,保洁网,笔记本电脑维修网,笔记本维修网,币众筹,毕业论文下载,表白节,博客导航,博客群建,猜的拼音,财经网站源码,财务软件培训,采集插件,采集侠,彩色电视机维修视频,茶叶中咖啡因的提取,畅享网,超人社区,超神传官网,成吉思汗1,成吉思汗2配置,成吉思汗2下载,成吉思汗sf,成人玩具网站,成人用品网址,初中数学资源网,穿越online,传奇1.76服务端,传奇1.76客户端,传奇1.76客户端下载,传奇1.76客户端下载完整版,传奇3 1.45 13魔法,传奇3 42魔法,传奇3客户端,传奇4g,传奇刺客私服,传奇客户端1.76版,传奇客户端下载1.76,传奇世界2.0,传奇私服刺客,传三私服,传世2.0,传世服务端,传说online,创富资源网,创业宝典,创业点子吧,创业点子网,刺客帝国,刺客私服,打印机培训,打印机维修培训,打印机维修视频,大话战国2,大闹天宫ol激活码,大闹天宫ol礼包,大闹天宫ol网页游戏,大闹天宫ol游戏,大闹天宫网页游戏,大唐豪侠下载,大学生交友,代理主机,贷齐乐,单片机视频教程下载,单片机学习视频,单片机学习网,单片机学习网站,弹弹堂单机版,弹弹堂客户端,蛋清ol,刀剑sf,刀剑私服,导航网站模板,盗号工具,盗梦侠,稻田黄鳝养殖技术,地方门户网,地方门户网站,地方门户网站系统,地区门户,地下城与勇士台服,帝国传奇私服,帝国模板,第六世界,第三方支付系统,第一人称射击网游,点评系统,电冰箱维修视频,电磁炉维修视频,电饭煲维修视频,电炉维修网,电脑技术教程,电脑上手机wap,电脑时间校对,电脑时间校准,电脑维修网站,电脑维修网站源码,电脑维修学习网站,电脑学习网,电脑学习网站,电脑资源,电脑组装视频教程,电视机维修视频,电视机维修视频教程,电视机维修网,电压力锅使用说明书,电压力锅说明书,电影网站程序,电影网站源码,电影源代码下载,电子商务源码,钓鱼网站源码,东游网,抖音资源视频在线观看,斗破苍穹2游戏,短文网,多多返利网,多多淘宝客,儿童教育资源网,儿童摄影模板,发泄网站,发型设计视频,发型设计视频教程,凡客v网上商城,凡客团购网,凡客网上购物商城,凡人修真网页游戏,泛站群,泛站群软件,防盗门网,房产网程序,房产网源码,仿快乐麻花,飞飞世界私服,分类信息系统,分享派,分享社区,封神网页游戏,疯狂蚂蚁,佛教网站源码,付费看电影,付费音乐网站,付费阅读网站,复印机培训,搞笑图片网,搞笑网站,歌曲批量下载,工程资料网,工业资源网,公司网站源码,公众号付费阅读,共享资源网,狗扑电影网,购物分享社区,购物分享网,购物分享网站,购物系统,光线cms,光线cms系统,广告联盟程序,广告任务,国家建筑标准设计网,海盗王1.38,海量小说网,海螺网购物分享社区,邯郸同城交友网,韩国化妆视频,横版三国,横版三国官网,红娘交友,猴岛网,猴岛游戏网,猴子岛论坛,猴子论坛,厚道论坛,互刷信誉平台,花边新闻网,华星国际,华中帝国,华中帝国技术论坛,华中帝国论坛,华中黑客帝国,化妆视频教程大全,画皮2ol,画皮2网页版,画皮2网页游戏,画皮2游戏,画皮2游戏官网,幻灯片代码,幻想游戏3.0,黄骅港潮汐表,黄鳝养殖技术大全,黄鳝养殖技术培训,黄鳝养殖技术视频,黄鳝养殖视频,会计电算化实务操作视频,婚嫁类网站,婚庆网站模板,机械工艺手册,机战世界解压密码,机战网络游戏,唧唧帝,唧唧帝笑话大全,唧唧帝笑话网,集群网,家教源码,建站之星模板,建站之星破解,建站之星破解版,剑网3私服,剑侠1私服,剑侠online,剑侠情缘 私服,剑侠情缘1私服,剑侠情缘3私服,剑侠情缘叁online,剑侠情缘网络版私服,剑侠世界sf,剑侠世界多玩论坛,剑侠世界私服发布网,剑侠私服,剑踪,将军令网站,交友程序,交友源码,教师节节目,街头篮球客户端下载,街头篮球私服,街舞教程,杰奇模版,解题网,金蛋网上商城,金蝶k3财务软件教程,金蝶k3视频教程,金蝶财务软件教程,金蝶财务软件视频教程,金蝶软件视频教程,金庸群侠传单机版,劲爆篮球下载,惊天战神官网,竞价单页,巨商私服,聚宝盆网,聚餐团购,聚美优品商城,决战sf,决战私服网,绝对女神私服,卡盟服务器,卡盟源码,开心ol私服,开心online私服,开心狗狗,开心淘开心,开心网代码,开运网,抗旱救灾,可外链的网盘,可外链网盘,克隆网站,刻字机维修,客户通讯录管理系统,客客网,空调维修大全,空调维修教程,空调维修视频教程,空间日志代码,空冥诀,酷开分享网,酷我资料网,酷源cms,快手作品点赞网站,昆仑online,乐淘网首页,乐网卡盟,乐享微信,冷柜维修,冷面汤怎么调,李居明官方网站,李居明视频,李居明网站,立刻贷,联盟程序,炼狱online,猎魂ol,裂变红包,六个方面对照检查材料,龙online,龙驹私服,龙腾世界sf,龙腾世界私服,龙心传奇,龙之谷 单机,龙之谷 单机版,龙之谷单机版,龙之谷单机版好玩吗,龙之谷单机版下载,龙珠online,龙珠网络游戏,鲁大师2013官方,鲁大师2013官方网,路尼亚,路尼亚战记官网,路尼亚战记私服,路尼亚战记台服,路尼亚战记下载,论坛模板,萝莉有杀气,洛克外挂,洛克王国 外挂,洛克王国waigua,洛克王国无毒外挂,麻辣香锅配方,马克斯程序,麦包包商城,漫画分享,猫扑贴贴,猫扑贴贴炫图库,猫扑炫图库,玫瑰镜糕,每推推,美甲视频下载,美丽说吧,美丽说团购,美丽说网站,美容上门服务,美文网文学,门户程序,门户模板,门户网站源码,门户站模板,梦幻卡修,梦幻龙族sf,梦幻诛仙服务器,梦回资源网,免费 网站,免费盗号软件,免费分享,免费分享网,免费共享,免费建论坛,免费图书,免费图书网,免费网络资源,面包网 奇热,明朝江湖,模板论坛,摩卡世界,蘑葫街 首页,魔界ol,魔界online,魔客吧,魔客网,魔力宝贝单机版,魔神契约,魔神争霸官网,魔兽3.35,魔兽世界服务端,魔咒ol,墨白资源网,母婴分享,木木不哭视频网站,南瓜园电影网,内涵图网,牛bb,农产品超市,农场2.0,女人世界网,女性门户,跑跑猴岛游戏论坛,跑跑卡丁车猴岛,烹调技术,朋友圈红包,捧腹网搞笑图片,捧腹笑话,霹雳舞教程,霹雳舞教学,漂亮网,平面广告设计师,平面设计素材网,七龙珠 online,七龙珠ol,七龙珠ol下载,七龙珠online,七龙珠online下载,七龙珠大型网络游戏,七龙珠网络游戏,七龙珠网络游戏大全,奇幻网游,奇迹客户端,奇迹生命之光,奇热电影网,奇热网 面包网,奇热网电影,骑士online,启点在线,千酷,强制加群,抢票助手,亲子活动网,亲子资源,亲子资源网,情人节网站,糗事百科网,趣玩网首页,全民暗黑,热奇网,热血传奇1.76客户端,热血传奇1.76客户端下载,热血江湖8.0,人人农场,日月传说,日月传说官网,日主题美化,融贷网,三国群英传ol单机版,三国演义ol,三国演义ol官网,三国演义ol礼包,三国演义ol论坛,三国演义ol什么职业好,三国演义网页游戏,三国演义游戏单机版,三界乾坤无限元宝,三五分类目录,三洋电饭煲维修,沙画教学视频,沙画培训,沙画学习,沙画学习教程,闪客网,商品资源网,商业网页游戏,上传歌曲的网站,烧菜网,社区动力,摄影网址大全,深度rom,什么值得买网,神马影院php源码,神奇黄鳝养殖技术,神奇影院首页,神泣单机版,神泣资源解包工具,神战九天,生成html,生死格斗ol单机版,生死格斗ol官网,生死格斗online,生死格斗单机版,生与死ol,师傅tv,石器时代2单机版,实物卡,食品商城,视频购物,视频聚合,视频压缩器,室外给水规范,收费视频,手机淘宝客,兽血沸腾私服,兽血沸腾游戏,蜀门游戏,蜀山神话官网,数学分析下册答案,水泥厂实习报告,私服登陆器,私服登录器,私服登入器,私服源码,搜狗资源,搜鱼,苏泊尔电压力锅使用,苏泊尔电压力锅使用方法,苏泊尔电压力锅使用说明书,苏泊尔高压锅说明书,素材火,她他社,淘宝导购网,淘宝导购网站,淘宝购物分享网站,淘宝互刷信誉,淘宝互刷信誉平台,淘宝刷单平台飞钻网,淘宝刷单平台首选米粒网,淘宝信誉互刷,淘客模板,特色小吃技术,天机ol,天机online,天龙八部2单机版,天龙八部3单机版,天堂1私服架设,天堂1私服网,天堂2服务端,天之炼狱2私服,天之刃官网,通达oa破解,同好网,偷拍工具,图片网站程序,图章生成器,兔兔影视网,兔子电影网,团购网源码,团购网站源码,沱沱工社官网,瓦罐营养快餐,外链网盘,外贸网站源码,完美世界国际版代码,网金单机,网络公司源码,网络购物分享网站,网络游戏单机版,网模招聘,网盘外链,网钛,网校资源,网页游戏服务端,网页游戏画皮2,网页游戏选22ck,网页游戏源码,网游热血三国,网站二次开发,网站集群系统,网站建设资源,微测评,微测试,微交易系统,微论坛,微信打车,微信端,微信跳转,问天ol,窝窝世界,我爱模板网,我要分享网,无限视距,无线营销,希望ol单机版,希希免费资源网,犀牛教程下载,犀牛软件视频教程,溪谷游戏,系统之家下载站,下载qq音速游戏,仙ol,仙境online,仙境传说单机版,仙境传说单机版技能,仙境传说单机版中文,仙侣奇缘2官网,小吃技术配方,小吃技术配方大全,小吃制作方法,小黑屋资源网,小蚂蚁门户,小蚂蚁网,小秘书网,小品大全网,小品屋,小饰品网站,小说搜索器,小说搜索网站,笑傲江湖ol捏人代码,笑傲江湖网游,笑话网站源码,新海盗王单机版,新浪发号,新闻网站源码,新仙剑ol激活码,新站长源码,新诛仙2,信誉刷钻,星尘传说sf,星尘传说单机,星尘传说服务端,星际文明ol,星际文明online,星空梦幻龙族,星空战记sf,星空战记官网,星外模板,虚拟wifi,虚拟主机系统,学电脑组装维修,学士学位申请理由,学校网站源码,训犬视频,讯类,讯睿,迅雷看看vip账号,迅游加速器免费账号,迅游加速器破解版2013,迅游破解版,要饭网,也买酒网,液晶显示器故障,液晶显示器维修教程,液晶显示器维修视频,一键内存清理,一手日源码资源,衣橱网,倚天2官网,倚天2龙驹,倚天2私服,易乐圈,易优网,音乐上传网站,音乐网站程序,音乐网站源码,英文外链,英语程序,营销软件站,影视热播网,影视搜,影音系统,影子资源网,佣兵天下游戏,永恒之塔单机版,优酷付费破解,悠悠电影网,游戏代练网,游戏美女陪玩价格表,游戏陪玩服务网站,游戏陪玩女,游戏陪玩网,游戏陪玩网站,游戏推广网站,游戏推广系统,游戏网站推广,有道海量词典,幼child video,鱼虾蟹游戏下载,娱乐门户,雨轩范文网,育儿健康,御剑江湖单机版,御剑江湖服务端,御剑江湖一键端,原创qq技术,源代码教育,源代码剧情介绍,源码爱好者,源码程序,源码集合,源码搜藏网,源码天下,远程视频嗅探器,运程测算,在线记帐,在线记账,在线客服程序,在线客服系统 源码,在线客服源码,在线资源库,战国online,战火红色警戒,站酷 素材,站酷素材,站酷素材网,站长目录,折800明日预告,真封神gm命令,真封神服务端,征途sf外挂,征途sf网站,征途服务端,征途私服客户端,征途私服客户端下载,征途私服网,征途私服网站,征途网络,征战四方2,政府cms,政府网站模板,支付宝红包口令分享,织梦采集侠,织梦二次开发,直销商城,致富机械,致富机械网,中国暗黑世界,中国创业点子网,中华特色小吃技术配方大全,中华养生网,中易广告联盟,周易 源码,诛仙online,诛仙服务端,诛仙网络游戏,主题资源,专业技术资格评审表,资料文档,资源爱好者,资源共享软件,自动答题器,自动发卡平台程序,自动售卡,足疗的手法,足疗视频教程,足疗手法,足疗手法视频,最好的农业网站,最新决战私服,最游记ol,醉品,醉品网,做菜网