新浪微博nosql,新浪微博登录

新浪微博「点赞功能」数据库如何设计的？

对于第一个问题，设计一个schema-(messageID，likedCount)，记录每条微博的点赞数。messageID是微博的编号，likedCount是该微博的点赞人数。但是这里有两个问题需要解决，第一是并发，第二是数据量。

创新互联专注于古浪网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供古浪营销型网站建设，古浪网站制作、古浪网页设计、古浪网站官网定制、小程序定制开发服务，打造古浪网络公司原创品牌,更为您提供古浪网站排名全网营销落地服务。

每条微博都有可能有很多人同时点赞，为了保证点赞人数精确就需要保证likedCount++是原子操作，这个可以由应用程序来实现，也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话)，但是我觉得为了性能考虑，也可以不用实现原子操作，具体原因就不展开了。

每天都上亿可能更多的微博内容产生，这样就会有上亿个新的(messageID，likedCount)生成，这样的数据量是比较大的，单机数据库比较难提供高效的服务，所以需要采取sharding的功能(有时候也叫分表分库)，可能根据messageID把这些schema分散到十个或者更多的shards上(据说，sina微博有600个节点，如何三个节点组成一个shard，就有200个shards)，这样每个shard处理的请求就只有原来的十分之一，从而就能提高服务的性能。

关于点赞人列表的设计，一般来说，可能想到的schema是(messageID，userID)，但是这样的设计有一个小问题，就是有些大发的微博可能会得到几十万的点赞，这样就会产生几十万个条数据，这样数据有点多，读取起来可能也慢。所以可以用这样一个schema(messageID，partID，userIDs)，让一个messageID对于多个userID，同时比对应太多的userID，所以加入一个新的partID，一个part存1000个userID，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点击查看点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

java web开发缓存方案，ehcache和redis哪个更好

java web开发缓存方案，ehcache和redis各有优劣势，对比如下：

1、适合使用ehcache的场景：

选用Ehcache作为数据存储服务器，Ehcache也是基于内存存储，支持定时持久化功能，非常适合存储像计数器这种小数据类型。处理Http请求使用Tomcat容器，结构图如下：

实现原理：处理逻辑采用一个servlet实现，并且在这个servlet中通过一致性Hash从Ehcache中获取计数器值。

2、高并发并且对实时性要求高的场合下使用redis

redis

redis是在memcache之后编写的，大家经常把这两者做比较，如果说它是个key-value store 的话但是它具有丰富的数据类型，我想暂时把它叫做缓存数据流中心，就像现在物流中心那样，order、package、store、classification、distribute、end。现在还很流行的LAMP PHP架构 不知道和 redis+mysql 或者 redis + mongodb的性能比较（听群里的人说mongodb分片不稳定）。

先说说reidis的特性

1. 支持持久化

redis的本地持久化支持两种方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化触发器，AOF指的是redis没增加一条记录都会保存到持久化文件中（保存的是这条记录的生成命令），如果不是用redis做DB用的话还会不要开AOF ，数据太庞大了，重启恢复的时候非常麻烦。

2.丰富的数据类型

redis 支持 String 、Lists、sets、sorted sets、hashes 多种数据类型,新浪微博会使用redis做nosql主要也是它具有这些类型，时间排序、职能排序、我的微博、发给我的这些功能List 和 sorted set 的强大操作功能息息相关。

3.高性能

这点跟memcache很想象，内存操作的级别是毫秒级的比硬盘操作秒级操作自然高效不少，较少了磁头寻道、数据读取、页面交换这些高开销的操作！这也是NOSQL冒出来的原因吧，应该是高性能

是基于RDBMS的衍生产品，虽然RDBMS也具有缓存结构，但是始终在app层面不是我们想要的那么操控的。

4.replication

redis提供主从复制方案，跟mysql一样增量复制而且复制的实现都很相似，这个复制跟AOF有点类似复制的是新增记录命令，主库新增记录将新增脚本发送给从库，从库根据脚本生成记录，这个过程非常快，就看网络了，一般主从都是在同一个局域网，所以可以说redis的主从近似及时同步，同事它还支持一主多从，动态添加从库，从库数量没有限制。 主从库搭建，我觉得还是采用网状模式，如果使用链式（master-slave-slave-slave-slave·····）如果第一个slave出现宕机重启，首先从master 接收 数据恢复脚本，这个是阻塞的，如果主库数据几TB的情况恢复过程得花上一段时间，在这个过程中其他的slave就无法和主库同步了。

5.更新快

这点好像从我接触到redis到目前为止 已经发了大版本就4个，小版本没算过。redis作者是个非常积极的人，无论是邮件提问还是论坛发帖，他都能及时耐心的为你解答，维护度很高。有人维护的话，让我们用的也省心和放心。目前作者对redis 的主导开发方向是redis的集群方向。

怎样用python爬新浪微博大V所有数据

我是个微博重度用户，工作学习之余喜欢刷刷timeline看看有什么新鲜事发生，也因此认识了不少高质量的原创大V，有分享技术资料的，比如好东西传送门；有时不时给你一点人生经验的，比如石康；有高产的段子手，比如银教授；有黄图黄段子小能手，比如阿良哥哥 木木萝希木 初犬饼…

好吧，我承认，爬黄图黄段子才是我的真实目的，前三个是掩人耳目的…（捂脸，跑开）

另外说点题外话，我一开始想使用Sina Weibo API来获取微博内容，但后来发现新浪微博的API限制实在太多，大家感受一下：

只能获取当前授权的用户（就是自己），而且只能返回最新的5条，WTF！

所以果断放弃掉这条路，改为『生爬』，因为PC端的微博是Ajax的动态加载，爬取起来有些困难，我果断知难而退，改为对移动端的微博进行爬取，因为移动端的微博可以通过分页爬取的方式来一次性爬取所有微博内容，这样工作就简化了不少。

最后实现的功能：

输入要爬取的微博用户的user_id，获得该用户的所有微博

文字内容保存到以%user_id命名文本文件中，所有高清原图保存在weibo_image文件夹中

具体操作：

首先我们要获得自己的cookie，这里只说chrome的获取方法。

用chrome打开新浪微博移动端

option+command+i调出开发者工具

点开Network，将Preserve log选项选中

输入账号密码，登录新浪微博

找到m.weibo.cn-Headers-Cookie，把cookie复制到代码中的#your cookie处

cookie

然后再获取你想爬取的用户的user_id，这个我不用多说啥了吧，点开用户主页，地址栏里面那个号码就是user_id

将python代码保存到weibo_spider.py文件中

定位到当前目录下后，命令行执行python weibo_spider.py user_id

当然如果你忘记在后面加user_id，执行的时候命令行也会提示你输入

最后执行结束

iTerm

小问题：在我的测试中，有的时候会出现图片下载失败的问题，具体原因还不是很清楚，可能是网速问题，因为我宿舍的网速实在太不稳定了，当然也有可能是别的问题，所以在程序根目录下面，我还生成了一个userid_imageurls的文本文件，里面存储了爬取的所有图片的下载链接，如果出现大片的图片下载失败，可以将该链接群一股脑导进迅雷等下载工具进行下载。

另外，我的系统是OSX EI Capitan10.11.2，Python的版本是2.7，依赖库用sudo pip install XXXX就可以安装，具体配置问题可以自行stackoverflow，这里就不展开讲了。

下面我就给出实现代码（严肃脸）

Python

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

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

#-*-coding:utf8-*-

import re

import string

import sys

import os

import urllib

import urllib2

from bs4 import BeautifulSoup

import requests

from lxml import etree

reload(sys)

sys.setdefaultencoding('utf-8')

if(len(sys.argv) =2):

user_id = (int)(sys.argv[1])

else:

user_id = (int)(raw_input(u"请输入user_id: "))

cookie = {"Cookie": "#your cookie"}

url = 'd?filter=1page=1'%user_id

html = requests.get(url, cookies = cookie).content

selector = etree.HTML(html)

pageNum = (int)(selector.xpath('//input[@name="mp"]')[0].attrib['value'])

result = ""

urllist_set = set()

word_count = 1

image_count = 1

print u'爬虫准备就绪...'

for page in range(1,pageNum+1):

#获取lxml页面

url = 'hu/%d?filter=1page=%d'%(user_id,page)

lxml = requests.get(url, cookies = cookie).content

#文字爬取

selector = etree.HTML(lxml)

content = selector.xpath('//span[@class="ctt"]')

for each in content:

text = each.xpath('string(.)')

if word_count = 4:

text = "%d :"%(word_count-3) +text+"\n\n"

else :

text = text+"\n\n"

result = result + text

word_count += 1

#图片爬取

soup = BeautifulSoup(lxml, "lxml")

urllist = soup.find_all('a',href=re.compile(r'^mblog/oripic',re.I))

first = 0

for imgurl in urllist:

urllist_set.add(requests.get(imgurl['href'], cookies = cookie).url)

image_count +=1

fo = open("/Users/Personals/%s"%user_id, "wb")

fo.write(result)

word_path=os.getcwd()+'/%d'%user_id

print u'文字微博爬取完毕'

link = ""

fo2 = open("/Users/Personals/%s_imageurls"%user_id, "wb")

for eachlink in urllist_set:

link = link + eachlink +"\n"

fo2.write(link)

print u'图片链接爬取完毕'

if not urllist_set:

print u'该页面中不存在图片'

else:

#下载图片,保存在当前目录的pythonimg文件夹下

image_path=os.getcwd()+'/weibo_image'

if os.path.exists(image_path) is False:

os.mkdir(image_path)

x=1

for imgurl in urllist_set:

temp= image_path + '/%s.jpg' % x

print u'正在下载第%s张图片' % x

try:

urllib.urlretrieve(urllib2.urlopen(imgurl).geturl(),temp)

except:

print u"该图片下载失败:%s"%imgurl

x+=1

print u'原创微博爬取完毕，共%d条，保存路径%s'%(word_count-4,word_path)

print u'微博图片爬取完毕，共%d张，保存路径%s'%(image_count-1,image_path)

Oracle、DB2、MySQL、SQL Server、Sybase这几款数据的重点应用领域分别是哪些？比如电信、互联网、银行等等

这个事情需要展开来看

很多大型企业单位为了满足业务系统的使用需要，使用很强劲的服务器主机，以大型机、小型机为主。这些机器都不使用windows系统，所以SQL Server之类的数据库没办法在这种机器上运行。Oracle、DB2、Sybase之类的是主流，这几个数据库有很强大的技术支持团队，也是受到大企业欢迎的原因。

计算机水平国外还是比较高的，所以外国软件公司开发的针对大企业的软件也都要求在这种数据库上运行。

约定俗成，微软的操作系统和数据库由于不能运行在很强劲的主机上，所以只能给中小企业服务。微软系列的还有access数据库，基本上是为单机服务的。

至于MySQL基本上是为网站服务的，主要特点是免费，应用挺多，但是大企业信息化软件很少用，因为没有对应的业务支持人员，到时候出问题，找不到人，就出大事故了。

反过来再看数据库本身，都有参数说明，你仔细看看就知道了。很多小数据库本身底气就不足，并发数量、最大库文件等等参数标得很低，你说大企业动辄几T几P的数据，敢忘这种数据库上放吗？软件公司敢编写用这种数据库的软件吗？

再说说知名度，企业之间都会互相问，要是一个很小很便宜的数据库大家都用，都用得很好，市场占有率极高。自然口碑就好，大家就都用了。微软的sqlsever就是一个例子。从最开始的6.5基本上不能用到sql2000很成功，得到大量企业的认同，到现在出到2008版本，占有率很高了，就是口碑，可是它在大企业中使用不理想，所以还是占有中小企业。

分析这些数据库，应该多方面来看，不能只看参数，只看技术。你都分析好了，发现某个数据库不像大家说的，你能用，可是市场上找不到对应的软件，也没辙，除非你自己编写。