一种以ID特征为依据的数据分片(Sharding)策略

<p>假如您有一个应用程序,随着业务越来越有起色,系统所牵涉到的数据量也就越来越大,此时您要涉及到对系统进行伸缩(Scale)的 问题了。一种典型的扩展方法叫做“向上伸缩(Scale Up)”,它的意思是通过使用更好的硬件来提高系统的性能参数。而另一种方法则叫做“向外伸缩(Scale Out)”,它是指通过增加额外的硬件(如服务器)来达到相同的效果。从“硬件成本”还是“系统极限”的角度来说,“向外伸缩”一般都会优于“向上伸 缩”,因此大部分上规模的系统都会在一定程度上考虑“向外”的方式。由于许多系统的瓶颈都处在数据存储上,因此一种叫做“数据分片(Database Sharding)”的数据架构方式应运而生,本文便会讨论这种数据架构方式的一种比较典型的实现方式。</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><h1>简介</h1><p>数据分片,自然便是将整体数据分摊在多个存储设备(下文统称为“数据分区”或“分区”)上,这样每个存储设备的数据量相对就会小很多,以此满足系统的性能需求。值得注意的是,系统分片的策略有很多,例如常见的有以下几种:</p><ul> <li>根据ID特征:例如对记录的ID取模,得到的结果是几,那么这条记录就放在编号为几的数据分区上。</li> <li>根据时间范围:例如前100万个用户数据在第1个分区中,第二个100万用户数据放在第2个分区中。</li> <li>基于检索表:根据ID先去一个表内找到它所在的分区,然后再去目标分区进行查找。</li> <li>……</li></ul><p>在这些数据分片策略之中没有哪个有绝对的优势,选择哪种策略完全是根据系统的业务或是数据特征来确定的。值得强调的是:数据分片不是银弹,它对系统的性能和伸缩性(Scalability)带 来一定好处的同时,也会对系统开发带来许多复杂度。例如,有两条记录分别处在不同的服务器上,那么如果有一个业务是为它们建立一个“关联”,那么很可能表 示“关联”的记录就必须在两个分区内各放一条。另外,如果您重视数据的完整性,那么跨数据分区的事务又立即变成了性能杀手。最后,如果有一些需要进行全局 查找的业务,光有数据分片策略也很难对系统性能带来什么优势。</p><p>数据分片虽然重要,但在使用之前一定要三思而后行。一旦踏上这艘贼船,往往不成功便成仁,很难回头。在我的经验里,一个滥用数据分片策略而事倍功半的项目给我留下了非常深刻的印象(当然也有成功的啦),因此目前我对待数据分片策略变得愈发谨慎。</p><p>那么现在,我们便来讨论一种比较常见的数据分片策略。</p><h1>策略描述</h1><p>这里我先描述一个极其简单的业务:</p><ol> <li>系统中有用户,用户可以发表文章,文章会有评论</li> <li>可以根据用户查找文章</li> <li>可以根据文章查找评论</li></ol><p>那么,如果我要对这样一个系统进行数据分片又该怎么做呢?这里我们可以使用上面提到的第一种方式,即对记录的ID取模,并根据结果选择数据所在的分区。根据后两条业务中描述的查询要求,我们会为分区策略补充这样的规则:</p><ul> <li>某个用户的所有文章,与这个用户处在同一数据分区内。</li> <li>某篇文章的所有评论,与这篇文章处在用一数据分区内。</li></ul><p>您可能会说,似乎只要保证“相同用户文章在同一个数据分区内”就行了,不是吗?没错,不过我这里让文章和用户在同一个分区内,也是为了方便许多额外的操作(例如在关系数据库中进行连接)。那么假设我们有4个数据分区,那么它们内部的条目可能便是:</p><table border="1" cellpadding="5" cellspacing="0"> <tbody> <tr> <td>分区0</td> <td>分区1</td> </tr> <tr> <td> <ul> <li>User 4 <ul> <li>Article 8</li> <li>Article 12 <ul> <li>Comment 4</li> <li>Comment 16</li> </ul> </li> </ul> </li> <li>User 12</li> <li>Article 4</li> </ul> </td> <td> <ul> <li>User 1 <ul> <li>Article 5</li> <li>Article 9 <ul> <li>Comment 13</li> <li>Comment 17</li> </ul> </li> </ul> </li> <li>User 5</li> <li>Article 13</li> </ul> </td> </tr> <tr> <td>分区2</td> <td>分区3</td> </tr> <tr> <td> <ul> <li>User 2 <ul> <li>Article 10</li> <li>Article 14 <ul> <li>Comment 6</li> <li>Comment 10</li> </ul> </li> </ul> </li> <li>User 10</li> <li>Article 4</li> </ul> </td> <td> <ul> <li>User 7 <ul> <li>Article 7</li> <li>Article 11 <ul> <li>Comment 3</li> <li>Comment 15</li> </ul> </li> </ul> </li> <li>User 11</li> <li>Article 4</li> </ul> </td> </tr> </tbody></table><p>在 ID为0的分区中,所有对象的ID模4均为0,其他分区里的对象也有这样的规律。那么好,在实际应用中,如果我们需要查找“ID为2的用户”,便去第2分 区搜索便是;如果要查找“ID为8的文章的所有评论”那么也只要去第0分区进行一次查询即可。既然查询不成问题,那么我们该如何添加新记录呢?其实这也不 难,只要:</p><ul> <li>添加新用户时,随机选择一个数据分区</li> <li>添加新文章时,选择文章作者所在分区(可根据Article的UserID求模得到)</li> <li>添加新评论时,选择文章所在分区(可根据Comment的ArticleID求模得到)</li></ul><p>但 是,我们又如何保证新纪录的ID正好满足我们的分区规律?例如我们向第3分区添加的新数据,则它的ID必须是3、7、11等等。以前,我们可能会使用数据 库的自增列作为ID的值,但这似乎不能满足我们“取模”的要求。以前我们可能还会使用GUID,但是我们如何生成一个“被4模于3”的GUID呢?其实我 们还是可以使用自增ID来解决这个问题,只不过需要进行一些简单的设置。例如在SQL Server中,默认的自增ID属性为IDENTITY(1, 1),表示ID从1开始,以1为间距自动增长。于是我们在创建数据分区的时候,每个自增列的属性则可以设置为:</p><ul> <li>分区0:IDENTITY(4, 4)</li> <li>分区1:IDENTITY(1, 4)</li> <li>分区2:IDENTITY(2, 4)</li> <li>分区3:IDENTITY(3, 4)</li></ul><p>这样,ID方面的问题便交由数据库来关心吧,我们的使用方式和以前并没有什么区别。</p><h1>缺陷</h1><p>那么这个数据分片策略有什么缺陷呢?当然缺陷还是有很多啦,只是大多数问题可能还是要和业务放在一起考虑时才会凸显出来。不过有一个问题倒和业务关系不大:如果数据继续增长,单个数据分区的数据量也超标了,怎么办?</p><p>自 然,继续拆分咯。那么我们使用什么分区规则呢?和原先一致吗?我们举个例子便知。假设我们原有4个分区,有一个ID为1的用户落在第1分区里,他的文章也 都在这个分区里,ID分别是1、5、9、13、17等等。于是在某一天,我们需要将分区数量提高到5个(财力有限,一台一台来吧),在重新计算每篇文章所 在的分区之后,我们忽然发现:</p><ul> <li>ID为1的文章,模5余1,处在分区1。</li> <li>ID为5的文章,模5余0,处在分区0。</li> <li>ID为9的文章,模5余4,处在分区4。</li> <li>ID为13的文章,模5余3,处在分区3。</li> <li>ID为17的文章,模5余2,处在分区2。</li></ul><p>呼,5 个分区都齐了!这说明,如果我们保持记录原来的ID不变,是没有办法直接使用之前的分区规则——无论您扩展成几个分区,(即便是从4个到8个)也只能“缓 解”也不能“解决”这个情况。那么这时候该如何是好呢?例如,我们可以重新分配记录,改变原有ID,只是这么做会产生一个问题,便是外部URL可能也会随 着ID一起改变,这样对SEO的折损很大。为此,我们可以制作一个查询表:例如在查询小于1234567的ID时(这是“老系统”的最大ID),假设是 100,则根据查询表得知这条记录的新ID为7654321,再以此去数据源进行查找。解决这类问题的方法还有几种,但无论怎么做都会对新系统带来额外的 复杂度。而且,一次扩展也罢,如果以后还要有所扩展呢?</p><p>consistent-hahsing</p><p>有朋友可能会说,取模自然会带来这样的问题,那么为什么不用一致性哈希(Consistent Hash)呢? 现在一致性哈希是个很流行的东西,和Memcached一样,如果不用上就会被一些高级架构师所鄙视。不过在这里一致性哈希也不能解决问题。一致性哈希的 目的,是希望“在增加服务器的时候降低数据移动规模,让尽可能多的数据保留在原有的服务器”上。而我们现在的问题却是“在增加服务器的时候,让特征相同的 数据同样放在一起”。两个目标不同,这并不是一致性哈希的应用场景。</p><p>我在以前的一个项目中曾经用过这样的方法:根据对访问量与数据量的 预估,我们认为使用最多24个分区便一定可以满足性能要求(为什么是24个?因为它能被许多数字整除)。于是,从项目第一次在生产环境中部署时便创建了 24个数据分区,只不过一开始只用了2台服务器,每台服务器放置12个数据分区。待以后需要扩展时,则将数据分区均匀地迁移到新的服务器上即可。我们团队 当时便是用这种方法避免尴尬的数据分配问题。</p><p>没错,数据分区的数目是个限制,但您真认为,24个数据分区还是无法满足您的项目需求吗? 要知道,需要用上24个数据分区的项目,一般来说本身已经有充分的时间和经济实力进行架构上的重大调整(也该调整了,几乎没有什么架构可以满足各种数据规 模的需求)。此外,无论是系统优化还是数据分片都可以同时运用其他手段。</p><p>不过,我们目前还是想办法解决这个问题吧。</p><h1>策略改进</h1><p>我们之所以会遇到上面这个问题,在于我们没有选择好合适的策略,这个策略把一些重要的“要求”给“具体化”了,导致“具体化”后的结果在外部条件改变的时候,却无法重新满足原有的“要求”。还是以前面的案例来说明问题,其实我们“要求”其实是:</p><ul> <li>某个用户的所有文章,与这个用户处在同一数据分区内。</li> <li>某篇文章的所有评论,与这篇文章处在用一数据分区内。</li></ul><p>而我们“具体化”以后的结果却是:</p><ul> <li>某个用户的所有文章ID,与这个用户的ID模4后的余数相同。</li> <li>某篇文章的所有评论ID,与这篇文章的ID模4后的余数相同。</li></ul><p>之 所以能如此“具体化”,这是因为有“4个分区”这样的前提条件在,一旦这个前提条件发生了改变,则杯具无法避免。因此,我们在制定规则的时候,其实不应该 把前提条件给过分的“具体化”——具体化可以,但不能过度,得留有一定空间(这个稍后再谈)。打个比方,还是前面的条件(XX和XX处在同一数据分区 内),但我们换一种具体化的方式:</p><ul> <li>某个用户的所有文章ID的前缀,便是这个用户的ID。例如,ID为1的用户的所有文章,其ID便可能是1-A1、1-A2、1-A3……</li> <li>某篇文章的所有评论ID,与这个文章的ID使用相同前缀。例如,ID为3-A1的文章的所有评论,其ID便可能是3-C1、3-C2、3-C3……</li></ul><p>使 用这个策略,我们便可以保证与某个用户相关的“所有数据”都共享相同的“特征”(ID的前缀都相同),然后我们便可以根据这个特征来选择分区——例如,还 是以“取模”的方式。此时,我们已经确保了“相同分区内的所有数据都具备相同的特征”,即便分区数量有所调整,我们也只需要根据特征重新计算分区即可,影 响不大。而以前为什么不行?因为“模4的余数”只是“结果”而不是“特征”,这里的“特征”应该是“追本溯源后的用户ID相同”,而这一点已经体现在新的 策略中了。</p><p>还是通过图示来说明问题吧。假设原有4个分区,使用“取模”的策略:</p><table border="1" cellpadding="5" cellspacing="0"> <tbody> <tr> <td>分区0</td> <td>分区1</td> </tr> <tr> <td> <ul> <li>User 4 <ul> <li>Article 4-A1</li> <li>Article 4-A2 <ul> <li>Comment 4-C1</li> <li>Comment 4-C2</li> </ul> </li> </ul> </li> <li>User 12</li> <li>Article 12-A3</li> </ul> </td> <td> <ul> <li>User 1 <ul> <li>Article 1-A4</li> <li>Article 1-A5 <ul> <li>Comment 1-C3</li> <li>Comment 1-C4</li> </ul> </li> </ul> </li> <li>User 5</li> <li>Article 5-A6</li> </ul> </td> </tr> <tr> <td>分区2</td> <td>分区3</td> </tr> <tr> <td> <ul> <li>User 2 <ul> <li>Article 2-A7</li> <li>Article 2-A8 <ul> <li>Comment 2-C5</li> <li>Comment 2-C6</li> </ul> </li> </ul> </li> <li>User 10</li> <li>Article 10-A9</li> </ul> </td> <td> <ul> <li>User 7 <ul> <li>Article 7-A10</li> <li>Article 7-A11 <ul> <li>Comment 7-C7</li> <li>Comment 7-C8</li> </ul> </li> </ul> </li> <li>User 11</li> <li>Article 11-A12</li> </ul> </td> </tr> </tbody></table><p>当分区数量调整为5个之后(为了避免分区3空缺,我又补充了一些对象):</p><table border="1" cellpadding="5" cellspacing="0"> <tbody> <tr> <td>分区0</td> <td>分区1</td> </tr> <tr> <td> <ul> <li>User 10 <ul> <li>Article 10-A9</li> </ul> </li> <li>User 5</li> <li>Article 5-A6</li> </ul> </td> <td> <ul> <li>User 1 <ul> <li>Article 1-A4</li> <li>Article 1-A5 <ul> <li>Comment 1-C3</li> <li>Comment 1-C4</li> </ul> </li> </ul> </li> <li>User 11</li> <li>Article 11-A12</li> </ul> </td> </tr> <tr> <td>分区2</td> <td>分区3</td> </tr> <tr> <td> <ul> <li>User 2 <ul> <li>Article 2-A7</li> <li>Article 2-A8 <ul> <li>Comment 2-C5</li> <li>Comment 2-C6</li> </ul> </li> </ul> </li> <li>User 12</li> <li>Article 12-A3</li> <li>Article 7-A10</li> <li>Article 7-A11 <ul> <li>Comment 7-C7</li> <li>Comment 7-C8</li> </ul> </li> <li>User 7</li> </ul> </td> <td> <ul> <li>User 8 <ul> <li>Article 8-A12</li> <li>Article 8-A13 <ul> <li>Comment 8-C9</li> <li>Comment 7-C10</li> </ul> </li> </ul> </li> </ul> </td> </tr> <tr> <td>分区4</td> <td> </td> </tr> <tr> <td> <ul> <li>User 4 <ul> <li>Article 4-A1</li> <li>Article 4-A2 <ul> <li>Comment 4-C1</li> <li>Comment 4-C2</li> </ul> </li> </ul> </li> </ul> </td> <td> </td> </tr> </tbody></table><p>是不是很合理?</p><p>值 得一提的是,只要满足了“特征”这个要求,其实选择分区的方式并没有什么限制。例如,我们可以不用“取模”的方式,而是使用“一致性哈希”——没错,这里 就是一致性哈希的使用场景了。在利用“一致性哈希”来选择分区之后,在添加服务器的情况下便可以相对减少数据的迁移数量了。</p><p>当然,在实 现时还可以运用一些技巧。例如,我们的特征并非一定要“把用户ID作为前缀”——毕竟用户ID可能比较长,作为ID前缀还真有些难看(请想象把GUID作 为ID前缀,再加上另一个GUID作为ID主体的情景)。此时,我们可以把前提条件先进行一定程度的“具体化”(但就像之前提到的,不能过度),例如我们 可以把用户ID先进行取模,可能是1000万,便可以得到一个落在较大区间范围内的数字。然后,再把这个数字作BASE64编码,一下子前缀就缩小为4个 字符以内了。而且,1000万这个区间范围,无论是使用取模还是一致性哈希的方式来选择分区都非常可行,一般不会造成什么问题。</p><h1>总结</h1><p>数 据分片是系统优化的常用设计方式之一。正如前文所说的那样,数据分片的做法很多,本文提到的方式只是其中一种方式。这种根据ID特征的分片方式比较容易遇 到的问题之一,便是在数据分区数量改变时造成的规则冲突,这也正是我这篇文章所讨论的主要内容。从这个角度看来,其他一些分片方式,如创建时间也好,查找 表也罢,这样的问题反而不太常见。如果您有这方面的经验或是疑惑,也欢迎与我进行交流。</p><p>现在Web 2.0网站越来越热门了,此类项目的数据量也越来越大,从近几年的讨论形式可以看出,越来越多的人在强调什么大规模、高性能、或是海量数据。然后,似乎每 个人都会横向切分、纵向切分、缓存、分离。我猜,再接下来,估计又会有许多人以用关系型数据库为耻了吧?但是,想想这样的问题:博客园和JavaEye都 是国内技术社区的翘楚,它们都只用了1台数据库服务器。StackOverflow世界上最大的编程网站(它是使用ASP.NET MVC写的,兄弟们记住这个经典案例吧),似乎也只用了1台还是2台数据库服务器(可能配置比较高)及SQL Server。因此,即便是单台服务器,即便是使用关系型数据库,它在性能方面的潜力也是非常之高的。</p><p>因 此,数据分片应该只在需要的时候才做,因为它带来的复杂度会比中心存储的方式高出很多。这带来的结果是,可能您的应用程序还没有用足架构的能力就已经失败 了,这样各种投资也已经浪费了。假如您一开始用最简单的方式去做,可能很快会带来成长所需要空间及资源,此时再做更多投资进行架构优化也不迟——架构不是一蹴而就,而是演变得来的。当然,第一次投入多少复杂度是个需要权衡的东西,这也是考验架构师能力的地方。架构不是空中楼阁,而是各种真实资源调配的结果。</p>

阅读剩余部分 -

电商管家 下一个金矿?

传统品牌“触网”及大量初创电商企业的快速崛起,催生了庞大的电商服务新兴生态圈,包括联想、IDG在内的资本闻风而至。他们认为,未来这些公司中可能会产生几家上市公司。

阅读剩余部分 -

支付宝,网银在线,快钱 3大支付接口的集成与对比,统合实现

<p>[支付宝参数设置案例]
t1 = "https://www.alipay.com/cooperate/gateway.do?";
t4 = "images/alipay_bwrx.gif"
t5 = "推荐使用支付宝付款"
service = "trade_create_by_buyer"
agent = "商户号"
partner = "商户号"
sign_type = "MD5"
subject = "订单号:"&dingdan 
body = "seadori商城"</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p>
out_trade_no = 变量 '客户网站订单号,(现取系统时间,可改成网站自己的变量)
price = 变量 'price商品单价 0.01~50000.00
discount = "0" '商品折扣
show_url = "www.domain.com" '商品展示地址(可以直接写网站首页网址)
quantity = "1" '商品数量
payment_type = "1" '支付类型,(1代表商品购买)
logistics_type = "POST" '物流种类(快递)
logistics_fee = "0.00" '物流费用
logistics_payment = "BUYER_PAY" '物流费用承担(买家付)
logistics_type_1 = "EMS"
logistics_fee_1 = "0.00"
logistics_payment_1 = "BUYER_PAY" '物流费用承担(买家付)
seller_email = "xxx@xxxl.net" '(必须填)
key = "xxxxxx" '(必须填)
notify_url= "http://domain/alipay/Alipay_Notify.asp";</p><p>[网银在线参数设置案例]
key = "XXXX"
v_mid = "商户号"
v_amount="金额变量"
v_moneytype = "CNY" 选择人民币
style="0"
v_url="http://www.damain.com/Receive.asp";
remark1=""
remark2=""
下面参数直接调用上面的定义, 不用修改。
<input type="hidden" name="v_md5info" size="100" value="<%=v_md5info%>">
<input type="hidden" name="v_mid" value="<%=v_mid%>">
<input type="hidden" name="v_oid" value="<%=v_oid%>">
<input type="hidden" name="v_amount" value="<%=v_amount%>">
<input type="hidden" name="v_moneytype" value="<%=v_moneytype%>">
<input type="hidden" name="v_url" value="<%=v_url%>">
<input type="hidden" name="style" value="<%=style%>">
<input type="hidden" name="remark1" value="<%=remark1%>">
<input type="hidden" name="remark2" value="<%=remark2%>"></p><p>[快钱参数设置案例]
merchant_id = "XXXXX" '''商户编号
merchant_key = "XXXXX" '''商户密钥
orderid = 变量 '''订单编号
amount = 变量 '''订单金额
curr = "1" '''货币类型,1为人民币
isSupportDES = "2" '''是否安全校验,2为必校验,推荐
merchant_url = "http://www.domaini.com/99bill/receive.asp"; '''支付结果返回地址
pname = request("pname") '''支付人姓名
commodity_info = "xxx商品" '''商品信息
merchant_param = "" '''商户私有参数 (不用填写)</p><p>[比较]
(1)快钱和玩银在线一般只使用3个文件, SEND, RECEIVE, MD5 
SEND 文件发送参数,RECEIVE文件返回参数结果,MD5进行加密验证。 
而支付宝一般有一个INDEX(可以调用到网站的支付页面),INDEX调用网站的变量参数,然后发送到PAYTO文件,INDEX和PAYTO文件组合起来相当于SEND的功能,而其他的都相同。</p><p>(2)支付宝大部分是安全支付平台,顾客收到货后支付宝才会给商户顾客支付的额度,而快钱和网银在线,钱杀直接到商户的帐里面。
3家公司的费率都是1%,而没有初装费或者年费, 不过过不了多久,肯定会有这类收费的。
所有支付系统都是有交易失败的情况的, 支付宝的失败率最少, 然后是网银,然后是快钱。
支付宝对客户来说是最为安全的,因为可以保证不被商家欺骗,但交易过程会慢很多;网银是中国B2C支付系统中最成熟的,很多大公司都用网银,网银对商家来 说是最合适的;快钱和网银基本上一样, 只是快钱对快钱普通用户有费率优惠,快钱使用者以快钱帐户购买商家产品的时候会比网银占一点便宜,而且快钱也可以象网银那样, 不需要快钱帐户直接进行银行支付的。但快钱的系统交易失败率并不低。
想起以前用过的中国移动和中国联通的支付系统,一:手机支付接口开发调试的时候比较麻烦,特别是联通的, 是非常复杂的,有些公司开发手机支付接口花费1~2个月, 移动和联通的技术支持也非常差,很多情况都不会理睬,而最重要的是,他们的费率是20~40%, 这和网银的1%比起来,是晕死人的事情,不过在中国, 手机用户远比网上银行用户多,而中国的移动公司是垄断形的,这也是中国手机花费高的原因,要知道独裁政治和垄断企业是走到一起的。</p><p>[统合]
很多网站一般在支付结果页面只集成一个支付渠道。因为多个支付渠道集成在一个页面的时候会有一些问题出现。
(1)在一个支付页面内集成不同支付渠道的时候:
一般只支持一个接口。多个接口的时候调用的MD5,PAYTO等文件的定义不同,在一个页面头文件里无法引用多个文件。
可以不调用MD5,只调用PAYTO来实现3个支付系统全部运作, 但这个风险是很大的,没有进行MD5的加密,客户支付的钱不能保证到商户的帐户里面。这是有安全隐患的。PAYTO里面引用的MD5和外部SEND引用的 MD5几乎是一样的问津, 但不同支付渠道对MD5引用的路径会不同,肯定是有安全隐患的。
(2)在一个页面放多个按钮, 点击按钮跳转到SEND,INDEX等页面进行支付。
这个方法是最为方便的,但后面打开的SEND和INDEX等页面必须调用前面支付页面里的参数变量。
调用前一页参数的方法我在其他文章里详细说明过,在此不进行说明。</p>

阅读剩余部分 -

如何设置IIS播放FLV流媒体

<p>微软的windows2003 server默认并没有开启支持flv文件格式的功能,其实win2003是支持FLV文件的。原因是由于windows server 2003上并没有.FLV的这种mime-type类型,对于这一点Adobe给出了它的解决方案。请按以下步骤操作。</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p>如下:</p><p>1. 在window2003服务器上,找开IIS管理器。
2. 展开本地服务器名称,右击选择属性,在Internet信息服务标签上,点击最下方的计算机MIME映射下面的编辑按钮。
3. 点击”新类型”按钮,扩展名添上”.FLV”,内容类型(MIME)添上“flv-application/octet-stream”
4. 点击确定
5. 重新启动www服务。</p><p>尽管adobe提供了这种解决方法可以让.FLV工作,但仍会在许多情况下会出现意想不到的结果,仍会有许多.FLV不能正常的工作。下面有一种解决方法:前几步是一样的。</p><p>1. 在2003服务器上,找开IIS管理器。
2. 展开本地服务器名称,右击选择属性,在Internet信息服务标签上点击最下方的计算机MIME映射下面的编辑按钮。
3. 点击”新类型”按钮,扩展名添上”.FLV”,内容类型(MIME)添上"video/x-flv"
4. 点击确定
5. 重新启动www服务。</p><p>
对于FLV类型: 
打开Internet Information Services Manager(IIS),选择“本地计算机”-->用户站点-->打开“属性”-->“HTTP头”-->“MIME类型”- ->“新建”。扩展名=“.flv”MIME类型=“flv-application/octet-stream”,保存退出即可。</p><p>对于RMVB类型: 
打开Internet Information Services Manager(IIS),选择“本地计算机”-->用户站点-->打开“属性”-->“HTTP头”-->“MIME类型”- ->“新建”。扩展名=“.rmvb”MIME类型=“application”,保存退出即可。</p>

阅读剩余部分 -

ASP.NET配置权限错误

错误提示

c:windowsMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Filesrootc36f236a846e06f5App_global.asax.0fmsk0sy.dll: --"拒绝访问"。

解决办法

C盘 添加 IIS_IUSERS 的使用权限

或者C盘添加USER 用户组 与Everyone 用户组即可

在与SQL server建立连接时出现与网络相关的或特定与实例的错误

<p> 在与SQL server建立连接时出现与网络相关的或特定与实例的错误 ...........error 40 错误 SQL Server错误 02  .. 今天运行SQL 08的时候给我来个这个提示. 我就纳闷了...研究了半天 ..发现是有个服务没启动 .......在这里记录下 .方便一下跟我一样对SQL比较菜的童鞋们....</p><p>      1. 打开 SQL Server 2008 的配置管理器.</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p>      2. 点击SQL Server 服务选项 然后看右边...应该有4个服务.都是没有启动的</p><p>      3. 启动SQL Server(MSSQLSERVER)  即可</p><p>如果不行就再过看一眼下面的  MSSQLSERVER 的协议</p><p>   看TCP/IP 是不是启动了</p><p>   Shared Memory 也要启动 .</p>

阅读剩余部分 -

随机文章

最近回复

分类

其它

友情连接

推广链接