2014年1月31日星期五

Yupoo(又拍网)的系统架构

Yupoo!(又拍网) 是目前国内最大的图片服务提供商,整个网站构建于大量的开源软件之上。以下为其使用到的开源软件信息:

(信息来源:http://www.yupoo.com/info/about/)。

一、Yupoo的整体架构

http://www.linuxeden.com/upimg/allimg/130521/1143291607-0.jpg

二、程序语言的选择

Yupoo的服务器端开发语言主要是PHP和Python,其中PHP用于编写Web逻辑(通过HTTP和用户直接打交道), 而Python则主要用于开发内部服务和后台任务。在客户端则使用了大量基于MooTools框架的Javascript。 另外,Yupoo把图片处理过程从PHP进程里独立出来变成一个服务。这个服务基于nginx,作为nginx的一个模块开放REST API。

http://www.linuxeden.com/upimg/allimg/130521/1143293926-1.png

三、服务器的选用

选用Squid的原因是"目前暂时还没找到效率比 Squid 高的缓存系统,原来命中率的确很差,后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去,所以命中率彻底提高了。"

http://www.linuxeden.com/upimg/allimg/130521/1143295123-2.png

同时Yupoo也使用Python开发了YPWS/YPFS:

  • YPWS�Yupoo Web Server 是用 Python开发的一个小型 Web 服务器,提供基本的 Web 服务外,可以增加针对用户、图片、外链网站显示的逻辑判断,可以安装于任何有空闲资源的服务器中,遇到性能瓶颈时方便横向扩展。
  • YPFS�Yupoo File System 与 YPWS 类似,也是基于这个 Web 服务器上开发的图片上传服务器。

有网友留言质疑 Python 的效率,Yupoo 老大刘平阳在 del.icio.us 上写到 "YPWS用Python自己写的,每台机器每秒可以处理294个请求, 现在压力几乎都在10%以下"

四、Yupoo的消息系统

由于PHP的单线程模型,Yupoo把耗时较久的运算和I/O操作从HTTP请求周期中分离出来, 交给由Python实现的任务进程来完成,以保证请求响应速度。这些任务主要包括:邮件发送、数据索引、数据聚合和好友动态推送等等。PHP通过消息队列 (Yupoo用的是RabbitMQ)来触发任务执行。这些任务的主要特点为:

  • 由用户或者定时触发的
  • 耗时比较长的
  • 需要异步执行的

整个任务系统主要分为以消息分发、进程管理和工作进程组成。

http://www.linuxeden.com/upimg/allimg/130521/1143291505-3.png

五、数据库的设计

数据库一向是网站架构中最具挑战性的,瓶颈通常出现在这里。又拍网的照片数据量很大,数据库也几度出现严重的压力问题。和很多使用MySQL的 2.0站点一样,又拍网的MySQL集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。

http://www.linuxeden.com/upimg/allimg/130521/11432a3J-4.png

最初是由一台主库和一台从库组成,当时从库只用作备份和容灾,当主库出现故障时,从库就手动变成主库,一般情况下,从库 不作读写操作(同步除外)。随着压力的增加,加上了memcached,当时只用其缓存单行数据。 但是,单行数据的缓存并不能很好地解决压力问题,因为单行数据的查询通常很快。所以把一些实时性要求不高的Query放到从库去执行。后面又通过添加多个 从库来分流查询压力,不过随着数据量的增加,主库的写压力也越来越大。在参考了一些相关产品和其它网站的做法后,进了行数据库拆分。也就是将数据存放到不 同的数据库服务器中。

如何进行数据库拆分?

  • 垂直拆分:是指按功能模块拆分,比如可以将群组相关表和照片相关表存放在不同的数据库中,这种方式多个数据库之间的表结构不同。
  • 水平拆分:而水平拆分是将同一个表的数据进行分块保存到不同的数据库中,这些数据库中的表结构完全相同。

一般都会先进行垂直拆分,因为这种方式拆分方式实现起来比较简单,根据表名访问不同的数据库就可以了。但是垂直拆分方式并不能彻底解决所有压力问 题,另外,也要看应用类型是否合适这种拆分方式。如果合适的话,也能很好的起到分散数据库压力的作用。比如对于豆瓣我比较适合采用垂直拆分, 因为豆瓣的各核心业务/模块(书籍、电影、音乐)相对独立,数据的增加速度也比较平稳。不同的是,又拍网的核心业务对象是用户上传的照片,而照片数据的增 加速度随着用户量的增加越来越快。压力基本上都在照片表上,显然垂直拆分并不能从根本上解决我们的问题,所以,Yupoo采用水平拆分的方式。

水平拆分实现起来相对复杂,我们要先确定一个拆分规则,也就是按什么条件将数据进行切分。 一般2.0网站都以用户为中心,数据基本都跟随用户,比如用户的照片、朋友和评论等等。因此一个比较自然的选择是根据用户来切分。每个用户都对应一个数据 库,访问某个用户的数据时, 要先确定他/她所对应的数据库,然后连接到该数据库进行实际的数据读写。那么,怎么样对应用户和数据库呢?Yupoo有这些选择:

1、按算法对应

最简单的算法是按用户ID的奇偶性来对应,将奇数ID的用户对应到数据库A,而偶数ID的用户则对应到数据库B。这个方法的最大问题是,只能分成两 个库。另一个算法是按用户ID所在区间对应,比如ID在0-10000之间的用户对应到数据库A, ID在10000-20000这个范围的对应到数据库B,以此类推。按算法分实现起来比较方便,也比较高效,但是不能满足后续的伸缩性要求,如果需要增加 数据库节点,必需调整算法或移动很大的数据集, 比较难做到在不停止服务的前提下进行扩充数据库节点。

2、按索引/映射表对应

这种方法是指建立一个索引表,保存每个用户的ID和数据库ID的对应关系,每次读写用户数据时先从这个表获取对应数据库。新用户注册后,在所有可用 的数据库中随机挑选一个为其建立索引。这种方法比较灵活,有很好的伸缩性。一个缺点是增加了一次数据库访问,所以性能上没有按算法对应好。

比较之后,Yupoo采用的是索引表的方式,我们愿意为其灵活性损失一些性能,更何况我们还有memcached, 因为索引数据基本不会改变的缘故,缓存命中率非常高。所以能很大程度上减少了性能损失。

http://www.linuxeden.com/upimg/allimg/130521/11432aP3-5.png

索引表的方式能够比较方便地添加数据库节点,在增加节点时,只要将其添加到可用数据库列表里即可。 当然如果需要平衡各个节点的压力的话,还是需要进行数据的迁移,但是这个时候的迁移是少量的,可以逐步进行。要迁移用户A的数据,首先要将其状态置为迁移 数据中,这个状态的用户不能进行写操作,并在页面上进行提示。 然后将用户A的数据全部复制到新增加的节点上后,更新映射表,然后将用户A的状态置为正常,最后将原来对应的数据库上的数据删除。这个过程通常会在临晨进 行,所以,所以很少会有用户碰到迁移数据中的情况。当然,有些数据是不属于某个用户的,比如系统消息、配置等等,把这些数据保存在一个全局库中。

分库带来的问题如何解决?

分库会给在应用的开发和部署上都带来很多麻烦。

1、不能执行跨库的关联查询

如果我们需要查询的数据分布于不同的数据库,没办法通过JOIN的方式查询获得。比如要获得好友的最新照片,不能保证所 有好友的数据都在同一个数据库里。一个解决办法是通过多次查询,再进行聚合的方式。所以需要尽量避免类似的需求。有些需求可以通过保存多份数据来解决,比 如User-A和User-B的数据库分别是DB-1和DB-2, 当User-A评论了User-B的照片时,我们会同时在DB-1和DB-2中保存这条评论信息,我们首先在DB-2中的photo_comments表 中插入一条新的记录,然后在DB-1中的user_comments表中插入一条新的记录。这两个表的结构如下图所示。这样我们可以通过查询 photo_comments表得到User-B的某张照片的所有评论, 也可以通过查询user_comments表获得User-A的所有评论。另外可以考虑使用全文检索工具来解决某些需求, 使用Solr来提供全站标签检索和照片搜索服务。

http://www.linuxeden.com/upimg/allimg/130521/11432a130-6.png

2、不能保证数据的一致/完整性

跨库的数据没有外键约束,也没有事务保证。比如上面的评论照片的例子, 很可能出现成功插入photo_comments表,但是插入user_comments表时却出错了。一个办法是在两个库上都开启事务,然后先插入 photo_comments,再插入user_comments, 然后提交两个事务。这个办法也不能完全保证这个操作的原子性。

3、所有查询必须提供数据库线索

比如要查看一张照片,仅凭一个照片ID是不够的,还必须提供上传这张照片的用户的ID(也就是数据库线索),才能找到它 实际的存放位置。因此,必须重新设计很多URL地址,而有些老的地址我们又必须保证其仍然有效。Yupoo把照片地址改成/photos /{username}/{photo_id}/的形式,然后对于系统升级前上传的照片ID, 又增加一张映射表,保存photo_id和user_id的对应关系。当访问老的照片地址时,通过查询这张表获得用户信息, 然后再重定向到新的地址。

4、自增ID重复的问题

如果要在节点数据库上使用自增字段,那么我们就不能保证全局唯一。这倒不是很严重的问题,但是当节点之间的数据发生关系 时,就会使得问题变得比较麻烦。再来看看上面提到的评论的例子。如果photo_comments表中的comment_id的自增字段,当我们在DB- 2.photo_comments表插入新的评论时, 得到一个新的comment_id,假如值为101,而User-A的ID为1,那么我们还需要在DB-1.user_comments表中插入(1, 101 …)。 User-A是个很活跃的用户,他又评论了User-C的照片,而User-C的数据库是DB-3。 很巧的是这条新评论的ID也是101,这种情况很用可能发生。那么我们又在DB-1.user_comments表中插入一行像这样(1, 101 …)的数据。 那么我们要怎么设置user_comments表的主键呢(标识一行数据)?可以不设啊,不幸的是有的时候(框架、缓存等原因)必需设置。那么可以以 user_id、 comment_id和photo_id为组合主键,但是photo_id也有可能一样(的确很巧)。看来只能再加上photo_owner_id了, 但是这个结果又让我们实在有点无法接受,太复杂的组合键在写入时会带来一定的性能影响,这样的自然键看起来也很不自然。所以,Yupoo放弃了在节点上使 用自增字段,想办法让这些ID变成全局唯一。为此增加了一个专门用来生成ID的数据库,这个库中的表结构都很简单,只有一个自增字段id。 当我们要插入新的评论时,我们先在ID库的photo_comments表里插入一条空的记录,以获得一个唯一的评论ID。 当然这些逻辑都已经封装在我们的框架里了,对于开发人员是透明的。 为什么不用其它方案呢,比如一些支持incr操作的Key-Value数据库。Yupoo还是比较放心把数据放在MySQL里。 另外,Yupoo会定期清理ID库的数据,以保证获取新ID的效率。

数据库优化的实现

前面提到的一个数据库节点为Shard,一个Shard由两个台物理服务器组成, 可以理解为Node-A和Node-B,Node-A和Node-B之间是配置成Master-Master相互复制的。 虽然是Master-Master的部署方式,但是同一时间还是只使用其中一个,原因是复制的延迟问题, 当然在Web应用里,可以在用户会话里放置一个A或B来保证同一用户一次会话里只访问一个数据库, 这样可以避免一些延迟问题。但是Python任务是没有任何状态的,不能保证和PHP应用读写相同的数据库。那么为什么不配置成Master-Slave 呢?Yupoo觉得只用一台太浪费了,所以在每台服务器上都创建多个逻辑数据库。 如下图所示,在Node-A和Node-B上我们都建立了shard_001和shard_002两个逻辑数据库, Node-A上的shard_001和Node-B上的shard_001组成一个Shard,而同一时间只有一个逻辑数据库处于Active状态。 这个时候如果需要访问Shard-001的数据时,我们连接的是Node-A上的shard_001, 而访问Shard-002的数据则是连接Node-B上的shard_002。以这种交叉的方式将压力分散到每台物理服务器上。 以Master-Master方式部署的另一个好处是,可以不停止服务的情况下进行表结构升级, 升级前先停止复制,升级Inactive的库,然后升级应用,再将已经升级好的数据库切换成Active状态, 原来的Active数据库切换成Inactive状态,然后升级它的表结构,最后恢复复制。 当然这个步骤不一定适合所有升级过程,如果表结构的更改会导致数据复制失败,那么还是需要停止服务再升级的。

http://www.linuxeden.com/upimg/allimg/130521/1143294430-7.png

前面提到过添加服务器时,为了保证负载的平衡,需要迁移一部分数据到新的服务器上。为了避免短期内迁移的必要,在实际部 署的时候,每台机器上部署了8个逻辑数据库, 添加服务器后,只要将这些逻辑数据库迁移到新服务器就可以了。最好是每次添加一倍的服务器, 然后将每台的1/2逻辑数据迁移到一台新服务器上,这样能很好的平衡负载。当然,最后到了每台上只有一个逻辑库时,迁移就无法避免了,不过那应该是比较久 远的事情了。

Yupoo把分库逻辑都封装在我们的PHP框架里了,开发人员基本上不需要被这些繁琐的事情困扰。下面是使用框架进行照片数据的读写的一些例子:

     array('type' => 'long', 'primary' => true, 'global_auto_increment' => true),                     'user_id'     => array('type' => 'long'),                     'title'       => array('type' => 'string'),                     'posted_date' => array('type' => 'date'),                 ));         $photo = $Photos->new_object(array('user_id' => 1, 'title' => 'Workforme'));         $photo->insert();         // 加载ID为10001的照片,注意第一个参数为用户ID         $photo = $Photos->load(1, 10001);         // 更改照片属性         $photo->title = 'Database Sharding';         $photo->update();         // 删除照片         $photo->delete();         // 获取ID为1的用户在2010-06-01之后上传的照片         $photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));     ?>

首先要定义一个ShardedDBTable对象,所有的API都是通过这个对象开放。第一个参数是对象类型名称, 如果这个名称已经存在,那么将返回之前定义的对象。你也可以通过get_table('Photos')这个函数来获取之前定义的Table对象。 第二个参数是对应的数据库表名,而第三个参数是数据库线索字段,你会发现在后面的所有API中全部需要指定这个字段的值。 第四个参数是字段定义,其中photo_id字段的global_auto_increment属性被置为true,这就是前面所说的全局自增ID, 只要指定了这个属性,框架会处理好ID的事情。

如果我们要访问全局库中的数据,我们需要定义一个DBTable对象。

     array('type' => 'long', 'primary' => true, 'auto_increment' => true),                     'username' => array('type' => 'string'),                 ));     ?>

DBTable是ShardedDBTable的父类,除了定义时参数有些不同(DBTable不需要指定数据库线索字段),它们提供一样的API。

六、缓存方案的选择

Yupoo使用的框架自带缓存功能,对开发人员是透明的。

load(1, 10001);     ?>

比如上面的方法调用,框架先尝试以Photos-1-10001为Key在缓存中查找,未找到的话再执行数据库查询并放入缓存。当更改照片属性或删除照片时,框架负责从缓存中删除该照片。这种单个对象的缓存实现起来比较简单。稍微麻烦的是像下面这样的列表查询结果的缓存。

fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));     ?>

Yupoo把这个查询分成两步,第一步先查出符合条件的照片ID,然后再根据照片ID分别查找具体的照片信息。 这么做可以更好的利用缓存。第一个查询的缓存Key为Photos-list-{shard_key}-{md5(查询条件SQL语句)}, Value是照片ID列表(逗号间隔)。其中shard_key为user_id的值1。目前来看,列表缓存也不麻烦。 但是如果用户修改了某张照片的上传时间呢,这个时候缓存中的数据就不一定符合条件了。所以,需要一个机制来保证我们不会从缓存中得到过期的列表数据。我们 为每张表设置了一个revision,当该表的数据发生变化时(调用insert/update/delete方法), 我们就更新它的revision,所以我们把列表的缓存Key改为Photos-list-{shard_key}-{md5(查询条件SQL语 句)}-{revision}, 这样我们就不会再得到过期列表了。

revision信息也是存放在缓存里的,Key为Photos-revision。这样做看起来不错,但是好像列表缓 存的利用率不会太高。因为我们是以整个数据类型的revision为缓存Key的后缀,显然这个revision更新的非常频繁,任何一个用户修改或上传 了照片都会导致它的更新,哪怕那个用户根本不在我们要查询的Shard里。要隔离用户的动作对其他用户的影响,我们可以通过缩小revision的作用范 围来达到这个目的。 所以revision的缓存Key变成Photos-{shard_key}-revision,这样的话当ID为1的用户修改了他的照片信息时, 只会更新Photos-1-revision这个Key所对应的revision。

因为全局库没有shard_key,所以修改了全局库中的表的一行数据,还是会导致整个表的缓存失效。 但是大部分情况下,数据都是有区域范围的,比如帮助论坛的主题帖子, 帖子属于主题。修改了其中一个主题的一个帖子,没必要使所有主题的帖子缓存都失效。 所以在DBTable上增加了一个叫isolate_key的属性。

 array('type' => 'long', 'primary' => true),             'post_id'     => array('type' => 'long', 'primary' => true, 'auto_increment' => true),             'author_id'   => array('type' => 'long'),             'content'     => array('type' => 'string'),             'posted_at'   => array('type' => 'datetime'),             'modified_at' => array('type' => 'datetime'),             'modified_by' => array('type' => 'long'),         ), 'topic_id');     ?>

注意构造函数的最后一个参数topic_id就是指以字段topic_id作为isolate_key,它的作用和shard_key一样用于隔离revision的作用范围。

ShardedDBTable继承自DBTable,所以也可以指定isolate_key。 ShardedDBTable指定了isolate_key的话,能够更大幅度缩小revision的作用范围。 比如相册和照片的关联表yp_album_photos,当用户往他的其中一个相册里添加了新的照片时, 会导致其它相册的照片列表缓存也失效。如果指定这张表的isolate_key为album_id的话, 我们就把这种影响限制在了本相册内。

缓存分为两级,第一级只是一个PHP数组,有效范围是Request。而第二级是memcached。这么做的原因是, 很多数据在一个Request周期内需要加载多次,这样可以减少memcached的网络请求。另外Yupoo的框架也会尽可能的发送memcached 的gets命令来获取数据, 从而减少网络请求。

参考文章:http://www.infoq.com/cn/articles/yupoo-partition-database

来自:http://www.biaodianfu.com/yupoo-architecture.html

业内曝淘宝数据泄漏事件内幕


核心提示:倒卖用户信息背后的隐秘产业链:做电商就是做数据。
电商从业人员会选择一些付费的"情报工具",通过搜索引擎、数据库等技术,对淘宝店进行数据分析,比如你店铺的竞争对手做了哪些直通车广告,用了哪些关键词,效果如何,以及行业分析、店铺分析、宝贝分析、买家搜索等,软件都可以提供。而这,在一些人眼里,就是"商机"

支付宝昨天爆发了数据泄露丑闻,超过20g的支付数据资料被支付宝前员工从系统中窃取出去,并出售给第三方,后被媒体曝光。

"支付宝内鬼盗卖用户信息被抓凡客被指是最大买家"相关事件的前后动态:

1,据报道,阿里巴巴旗下支付宝的前技术员工李明,利用工作之便,在2010年分多次在公司后台下载了支付宝用户的资料,资料内容超20G。李明伙同两位同伙,随后将用户信息多次出售予电商公司、数据公司。

2,犯罪嫌疑人张建系李明团伙的第一个"客户",其以500元的代价,从李明处购得3万条支付宝用户信息。

3,据李明等供述,支付宝用户的最大买家系服装类电商公司凡客诚品,其花重金从李明团伙手中购得支付宝用户资料1000万条。但这个说法没有得到警方的证实。

4, 1月2日晚间,凡客诚品一位副总裁向经济观察报表示:"不太清楚这件事,没听说过。" 如果有需要公司会积极配合调查。

5,张建所购的支付宝用户资料中,包括公民个人的实名、手机、电子邮箱、家庭住址、消费记录等,从这些定位精准的用户信息中,张建掌握了目标消费群体的具体信息。

这已经不是支付宝第一次发生此类事件了,前期谷歌等搜索引擎在网上能搜索到数百万条支付宝用户信息的事情,在引发了一些关注后戛然而止,从此很少被提及,此次用户隐私数据丑闻在支付宝公关部的努力下,也很可能很快远离公众视野,消弭于无形。

支付宝的用户数据包含大量用户隐私,如电话、地址、身份证号、购物习惯、账户余额等。如果这些资料被不法分子掌握,理论上他们可以用来实施很多犯罪行为,威胁到用户个人财务安全。

倒卖用户信息背后的隐秘产业链:做电商就是做数据!

随着电商的发展,客户精准定位越发重要。大多数做电商的人,尤其是做到一定规模的人,都会购买数据。

这些电商从业人员会选择一些付费的"情报工具",通过搜索引擎、数据库等技术,对淘宝店进行数据分析,比如你店铺的竞争对手做了哪些直通车广告,用了哪些关键词,效果如何,以及行业分析、店铺分析、宝贝分析、买家搜索等,软件都可以提供。通过使用这类软件,电商从业人员可以获取竞争对手的数据,以作为调整营销策略和产品定位的参考依据。

举个例子,比如卖女性内衣的,如果手上有一个数据库,得知喜欢在网上买内衣的女性消费者,她们购物的频次如何,价格区间如何,消费规律如何,喜欢什么品牌等 等,如果知道了这些信息,我就可以提炼出更多的信息,以调整店铺战略。如果再知道了她们的手机号码、电子邮箱、家庭住址等,甚至还可以向她们定向群发短 信、邮件、直邮DM等,她们都是精细化营销的潜在消费者!

李明离职前从支付宝下载的数据多达20G以上,只要通过一些软件录入数据库再予以专业分析的话,基本上可以将所有支付宝、淘宝用户的消费习惯尽收眼底。"这些用户信息,都是可以带来钱的,可以变现的。"

你所不知道的更多内幕:

知名IT人士@Fenng 在知乎上对此次事件爆料:

事情的起因是在去年。年底冲无线 KPI ,外面搞了一家公司,做中间商,冲交易流量… 而后某个环节出问题,被捅出来了。然后查出来一堆人。不知道高一级的管理者要承担责任不。

然后怎么搞出来数据的事情就不得而知了。应该是囚徒困境,互相揭发吧。

数据的事情则是 2010 年就发生了,很巧的是,那段时间我的确听到有朋友跟我说外面有这个数据,但我分析了一下,觉得可能是在 EDM 环节出问题,人都走了,也就不关心这事了。那段时间还是团购网站的数据最热。

因为权限控制问题,销售部门那个时间几乎可以任意调取数据,内审还没上来。据说这个权限控制问题,在 2011 年逐步改进了,当然,到现在应该彻底杜绝掉了,毕竟各个环节的审计都上来了。

当事人其实在阿里年头不短,也算有钱的了。但人心都是贪的啊。哪有止境。

出问题的人不是工程师。

工程师团队还都是挺靠谱的,其实那时尽管有各种针对运维部门的审计工具,但要绕过去还是易如反掌的,只是没人动这个心思。

因为工作关系,我曾经一度能接触到所有数据,真的,所有数据。制度都是针对人的。如果人犯了糊涂,做点手脚,这个真的很难防范。

大公司里面,一定级别的人外面开个公司,然后把市场费用什么的洗走,应该很常见了吧。这种事情永远都不会杜绝。

知名互联网分析师葛甲在其微信公众号上对此表示:

这名前支付宝员工在3年前就开始窃取支付数据,这是孤立行为还是普遍行为,支付宝那些通过了多重安全鉴定的内部管控机制到底能否起作用?

本次数据泄露事件是否如支付宝轻描淡写的那样,仅是违规操作行为,不涉及敏感信息。如果真是这样的话,为什么要动用公安机关抓人。

支付宝在数据泄露事件中要承担什么责任?这么大一个公司,要对自己的行为负责,李某的职务身份是支付宝员工,履行的是公司职责,这个责任不能简单推给个人或是全社会就完事儿了。

被交易的用户数据既然有交易价值,为何支付宝还要死硬抵赖说不涉及用户的敏感信息?什么算敏感信息?那些电商网站买去那些没有人名,没有ip地址、信用卡、身份证的信息回去是要做什么?真的没有敏感信息吗?

既然支付宝已说这些用来交易的用户信息并没有被传到网上,必然是已经弄清了数据流动的一切来龙去脉,为何不公布这些事实真相,并积极检讨自身,而是要努力推卸责任,并东拉西扯把别的企业牵扯进来?

中国人为什么喜欢讲关系?



近日有学者表示:中国社会虽历来讲究人情关系,但当下社会讲关系的风气已登峰造极。不少网友对此观点表示赞同。是啊,在中国谁都知道"关系"的重要。没有 "关系"简直寸步难行。小孩入学要不要关系?审批项目、找工作、做生意、看病等哪一样大家不是在找关系?有人甚至还总结出一句话:"在中国,关系就是生产 力。"那么,为什么中国人最喜欢讲关系呢?
关系在中国究竟能有多大的作用?

最近有网站对大学生 就业进行了一项调查,结果将近50%的大学生回答说是"要靠关系"――就是如果谁有关系,谁有门道,谁就最有可能找到一份好工作。而选择"有能力"、"有 创新精神"、"敢开拓"等因素的最多也不超过18%。而细观网友的留言则发现,即使是"能力派"们也都认为"应当双管齐下",甚至悲观地认为"靠能力只是 一种理想"。可见大多数人都难以否认关系的重要性。

有网友曾感叹,在中国其实连扫街女工都要讲关系。街道环卫管辖内的那么多 地段,有的垃圾多,有的垃圾少;有的车辆多,有的车辆少;有的容易扫到人造成矛盾,有的比较清净。拥有分配哪个地段给你的权力的环卫站长、书记,你要不要和他搞好关系,送点礼,分到一块好点的地段,比较容易清扫,没那么危险。如果不懂,如果不去搞好关系,那么最差的地段就是你的了。付出更多的体力精神,吸 入更多滚滚灰尘,却还要给差评,扣工资扣奖金。

这也许就是中国关系社会最真实的一个缩影。人们评职称,需要找关系;孩子找工 作,需要找关系;看病,需要找关系;上学,需要找关系。人们处处为建立关系而投资。人们为失去关系而苦恼,人们也为有良好关系而兴奋。关系,让人性扭曲化,也让道德边缘化。除此之外,在中国一个人的社会关系网越大,其中有权有势的人越多,他在别人心目中的权力形象也就越大。《西游记》不就告诉了我们:凡 是有后台的妖怪都被接走了,凡是没后台的都被一棒子打死了吗!

中国人的"关系学"

中国人把人的 关系分成了三种。一种叫家人关系,这是最核心的一层,家人关系里对利益保护没有条件,而且不讲回报。家人关系不好的时候,当然会有愤怒和敌意,但更多的是 忍耐,因为家丑不可外扬。第二层关系是熟人关系,比如同学、邻居、同事和同村乡亲。熟人关系对人情的回报有一些期待,会通融但也有条件。第三层关系则是中 国文化中最少涉及的生人关系。公事公办是生人关系的特点。生人之间往往不给任何照顾,只讲利害,对回报要求最高。
这些关系牢 牢地构筑了一张庞大的、坚不可破的社会关系网。一张看似温情脉脉,实际上充满了冷漠与不信任的网。每个人都渴望拥有一张能令他人羡慕的关系网,每个人都在 苦心、细心经营着自己的关系网,每个人都期望能从自己的关系网中获得利益,而关系网的最大本质,就在于相互利用、相互依靠。

于是,人人都拼命拉关系、走后门。然而,关系"资源分配永远不会平等,因为并不是所有人都能结识并有财力买通"后门"的"把门人",所以,那些拼命拉关系的 人,或许因偶尔获益而沾沾自喜,更多的情况下是看到别人走后门,自己没有关系而倍感沮丧,但不少人沮丧之后又激发了寻找后门的更顽强的"斗志",就这样, 人们屡战屡败,屡败屡战,最终形成了一个更加不公正的社会环境――一个具有中国特色的"后门困境"。

中国人何时才能不讲关系?

讲关系的可怕,正是在于他已经占据了人的大脑,影响了人的思维和判断。让每一个中国人在做什么事情之前,都要想,我有什么关系可以在这件事情上用的,还要再 拉哪些关系?而那些手上掌握着公权力的人,也习惯性的把许多明明是职责上应该做的事,就是故意的不做,等着人上来拉关系,收好处。一个人这样做,危害还不 是很大,全国的人都这样做呢?那样的话,政府会变成什么样子?国家会变成什么样子?

在西方,如果你认识关键、重要的人物,也 会更有利于你的职业升迁或商业成功,但即便你没有什么"关系",你也能存活,甚至活得不是太差。但在中国,如果你没有任何"关系",那就可能意味着你活不 下去,或至少活得很差。西方的人际联系固然也重要,但它不能超越法律、道德和规则,从这个意义上说,西方社会基本上是一个"规则社会"。中国社会则是一个 靠"关系"来调节和维系的社会,中国虽然也有法律,有道德,有规则,但"关系"可以超越法律,腐蚀道德,破坏规则,"关系"甚至可以造就法外之"法"和潜 规则。

目前的中国社会,关系文化已弥漫一切领域,已深入很多人的骨髓。但关系的存在,意味着对游戏规则的破坏,意味着不公 平。关系,让政治不能政治;关系,也让经济不能经济;关系,也让文化不能文化。密密麻麻的关系,就像一张密密的大网,罩在国家的头上,让国家发展举步维 艰。可以说,不打破关系网,中国的民主政治、法治社会等就很难真正实现。