http状态码查询表(转载)

HTTP状态码详解
本文详细解释了HTTP状态码的意义及用途,包括常见的200、404、500等状态码,并介绍了如何通过服务器日志查看这些状态码,帮助网站管理员了解网站运行状况。

这周做了一个应用小应用:就是以http的方式与远程门户网站进行交换,得到他们发送过来的数据信息。在开发中就遇到一个问题,本来如果远程的返回的状态码为200,则表示连接成功,可以开始接收数据了。可是测试的时候,发现返回的状态码为404,500等。自己当时也不知道是什么情况,于是google下,发现了一篇不错的文章,于是收录下,以备以后的查询。

文章地址为:

http://www.zh-seo.com/seo-jiaocheng/2009/0601/HTTP-status.html

做seo网站优化过程中需要经常查看服务器log日志信息,其中服务器log日志中就含有服务器返回的HTTP状态码信息已经搜索引擎蜘蛛或者机器人程序的访问时间。

什么是HTTP状态码?

     如果向您的服务器发出了某项请求要求显示您网站上的某个网页(例如,当用户通过浏览器访问您的网页或Googlebot抓取该网页时),那么,您的服务器会返回HTTP状态代码以响应该请求。此状态代码提供了有关请求状态的信息,且为Googlebot提供了有关您网站和请求的网页的信息。

HTTP状态码在哪里可以看到?

HTTP状态码我们可以在网站的log日志里可以看到,最常见的状态码就是200和404,不过log日志文件很多虚拟主机提供商都不提供,可能是他们为了节省空间。所以在购买虚拟空间之前最好多问问是否可以提供log日志文件下载。其实我们有时在打开某些网站时候会提示此页无法显示,或者不存在,这种情况一般就会返回404错误状态码。 

HTTP状态码有什么用?

HTTP状态码对于一般的访客来说没有太大用处,因为大部分访客都不知道怎么回事?比如出现了404错误,该页无法显示。访客只知道这个页面不存在了,或者输入错误了。而不知道怎么去解决,所有的HTTP状态码基本上都是让网站管理员看的,他们知道目前网站的基本情况,如出现5xx错误了,需要管理员检查一下服务器端出现什么故障了,需要对服务器进行维护。还有管理员可以在服务器log日志文件里看到搜索引擎机器人或者蜘蛛程序什么时候来爬取过网站,这对于seo(baidu优化google优化,百度优化)人员来说是很重要的信息。 

常见的HTTP状态码有哪些?这些状态码分别代表什么意思?

200 - 服务器成功返回网页
301 - 永久移动,请求的网页已被永久移动到新位置
404 - 请求的网页不存在,网页不存在。
500 - 服务器遇到错误,无法完成请求。
503 - 服务器暂时不可用,目前无法使用服务器(由于超载或进行停机维护)。通常,这只是一种暂时的状态。

HTTP 状态代码的完整列表  

1xx(临时响应)
用于表示临时响应并需要请求者执行操作才能继续的状态代码。

代码说明
100(继续)请求者应当继续提出请求。服务器返回此代码则意味着,服务器已收到了请求的第一部分,现正在等待接收其余部分。
101(切换协议)请求者已要求服务器切换协议,服务器已确认并准备进行切换。

2xx(成功)

用于表示服务器已成功处理了请求的状态代码。

代码说明
200(成功)服务器已成功处理了请求。通常,这表示服务器提供了请求的网页。如果您的服务器log日志文件显示为此状态,那么,这表示请求成功。
201(已创建)请求成功且服务器已创建了新的资源。
202(已接受)服务器已接受了请求,但尚未对其进行处理。
203(非授权信息)服务器已成功处理了请求,但返回了可能来自另一来源的信息。
204(无内容)服务器成功处理了请求,但未返回任何内容。
205(重置内容)服务器成功处理了请求,但未返回任何内容。与 204 响应不同,此响应要求请求者重置文档视图(例如清除表单内容以输入新内容)。
206(部分内容)服务器成功处理了部分 GET 请求。

3xx(已重定向)
要完成请求,您需要进一步进行操作。通常,这些状态代码是永远重定向的。Google建议:在每次请求时使用的重定向要少于5个。您可以使用网站管理员工具来查看Googlebot (google机器人程序)在抓取您已重定向的网页时是否会遇到问题。诊断下的抓取错误页中列出了Googlebot 由于重定向错误而无法抓取的网址。

代码说明
300(多种选择)服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作,或提供操作列表供请求者选择。
301(永久移动)请求的网页已被永久移动到新位置。服务器返回此响应(作为对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
302(临时移动)服务器目前正从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置。
303(查看其他位置)当请求者应对不同的位置进行单独的 GET 请求以检索响应时,服务器会返回此代码。对于除 HEAD 请求之外的所有请求,服务器会自动转到其他位置。
304(未修改)

自从上次请求后,请求的网页未被修改过。服务器返回此响应时,不会返回网页内容。如果网页自请求者上次请求后再也没有更改过,您应当将服务器配置为返回此响应(称为If-Modified-Since HTTP 标头)。

305(使用代理)请求者只能使用代理访问请求的网页。如果服务器返回此响应,那么,服务器还会指明请求者应当使用的代理。
307(临时重定向)服务器目前正从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置。但由于 搜索引擎会继续抓取原有位置并将其编入索引,因此您不应使用此代码来通知搜索引擎某个页面或网站已被移动。

4xx(请求错误)
这些状态代码表示,请求可能出错,已妨碍了服务器对请求的处理。

代码说明
400(错误请求)服务器不理解请求的语法。
401(未授权)请求要求进行身份验证。登录后,服务器可能会返回对页面的此响应。
403(已禁止)服务器拒绝请求。如果在搜索引擎尝试抓取您网站上的有效网页时显示此状态代码,那么,这可能是您的服务器或主机拒绝搜索引擎对其进行访问。
404(未找到)

服务器找不到请求的网页。例如,如果请求是针对服务器上不存在的网页进行的,那么,服务器通常会返回此代码。

如果您的网站上没有robots.txt 文件,而您在 Google 网站管理员工具"故障诊断"标签的"网络抓取"-"找不到"页上发现此状态。然而,如果您有robots.txt 文件而又发现了此状态,那么,这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。(该文件应当位于根目录下,且应当名为 robots.txt)。

如果您在Googlebot 尝试抓取的网址上发现此状态(位于"诊断"标签的 HTTP 错误页上),那么,这表示 Googlebot 所追踪的可能是另一网页中的无效链接(旧链接或输入有误的链接)。

405(方法禁用)禁用请求中所指定的方法。
406(不接受)无法使用请求的内容特性来响应请求的网页。
407(需要代理授权)此状态代码与 401(未授权)类似,但却指定了请求者应当使用代理进行授权。如果服务器返回此响应,那么,服务器还会指明请求者应当使用的代理。
408(请求超时)服务器等候请求时超时。
409(冲突)服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码,同时会提供两个请求的差异列表。
410(已删除)如果请求的资源已被永久删除,那么,服务器会返回此响应。该代码与 404(未找到)代码类似,但在资源以前有但现在已经不复存在的情况下,有时会替代 404 代码出现。如果资源已被永久删除,那么,您应当使用 301 代码指定该资源的新位置。
411(需要有效长度)服务器不会接受包含无效内容长度标头字段的请求。
412(未满足前提条)服务器未满足请求者在请求中设置的其中一个前提条件。
413(请求实体过大)服务器无法处理请求,因为请求实体过大,已超出服务器的处理能力。
414(请求的 URI 过)请求的 URI(通常为网址)过长,服务器无法进行处理。
415(不支持的媒体类型)请求的格式不受请求页面的支持。
416(请求范围不符合要求)如果请求是针对网页的无效范围进行的,那么,服务器会返回此状态代码。
417(未满足期望值)

服务器未满足"期望"请求标头字段的要求。

5xx(服务器错误)
这些状态代码表示,服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误,而不是请求出错。

代码说明
500(服务器内部错误)服务器遇到错误,无法完成请求。
501(尚未实施)服务器不具备完成请求的功能。例如,当服务器无法识别请求方法时,服务器可能会返回此代码。
502(错误网关)服务器作为网关或代理,从上游服务器收到了无效的响应。
503(服务不可用)目前无法使用服务器(由于超载或进行停机维护)。通常,这只是一种暂时的状态。
504(网关超时)服务器作为网关或代理,未及时从上游服务器接收请求。
505(HTTP 版本不受支持)服务器不支持请求中所使用的 HTTP 协议版本。

模块C:实时数据处理(25分) 环境说明: 服务端登录地址详见各模块服务端说明。 补充说明:各节点可通过Asbru工具或SSH客户端进行SSH访问; 主节点MySQL数据库用户名/密码:root/123456(已配置远程连接); Flink任务在Yarn上用per job模式(即Job分离模式,不采用Session模式),方便Yarn回收资源; 建议使用gson解析json数据。 任务一:实时数据清洗 编写Java代码,使用Flink消费Kafka中Topic的数据并进行相应的数据统计计算。 1、使用Flink消费Kafka中topic为topic1的数据,根据数据中不同的表将数据分别分发至kafka的DWD层的Topic中。使用Kafka自带的消费者消费Topic的前1条数据,将结果截图粘贴至客户端桌面【Release\模块C提交结果.docx】中对应的任务序号下; 2、使用Flink消费Kafka中topic为topic2的数据,将数据分别分发至kafka的DWD层的Topic中。使用Kafka自带的消费者消费Topic的前1条数据,将结果截图粘贴至客户端桌面【Release\模块C提交结果.docx】中对应的任务序号下; 在任务1、2进行的同时,需要将相关数据表备份至HBase中,使用HBase Shell查看ods:table1表的任意2条数据,查看字段为key1与key2、查看ods:table2表的任意2条数据,查看字段为key1与key2、查看ods:table3表的任意2条数据,查看字段为key1与key2。将结果分别截图粘贴至客户端桌面【Release\模块C提交结果.docx】中对应的任务序号下。 任务二:实时指标计算 编写Java工程代码,使用Flink消费Kafka中dwd层的Topic数据,表结构与离线数据表结构相同。 1、使用Flink消费kafka中的数据,统计商品的UV和PV,将结果写入HBase中的表ads:online_uv_pv中。使用Hive cli查询ads.pv_uv_result表,查询出10条数据,将结果截图粘贴至客户端桌面【Release\模块C提交结果.docx】中对应的任务序号下; 2、使用Flink消费kafka中的数据,统计商城每分钟的GMV,将结果存入redis中,key为store_gmv,使用redis cli以get key方式获取store_gmv值,将每次截图粘贴至客户端桌面【Release\模块C提交结果.docx】中对应的任务序号下(每分钟查询一次,至少查询3次)。 ———————————————— 版权声明:本文为优快云博主「旺仔Sec」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.youkuaiyun.com/qq_50377269/article/details/143791489
最新发布
11-01
<think>我们根据用户需求,分步骤实现以下任务: 1. 使用Flink(Java API)在Yarn的per job模式下消费Kafka的topic1和topic2(这里我们假设topic1对应ods_mall_log,topic2对应ods_mall_data,但具体以用户需求为准)进行实时数据清洗,并将清洗后的数据分发到DWD层的不同Topic(如fact_order_master, fact_order_detail等),同时将原始数据备份到HBase。 2. 使用另一个Flink作业消费DWD层的Topic(例如fact_order_master等)进行实时指标计算,包括: - 统计商品UV和PV,并将结果写入HBase - 统计商城每分钟GMV( Gross Merchandise Volume,商品交易总额),并将结果存入Redis 由于用户要求使用Java,我们将提供Java代码示例。同时,由于操作指导涉及到Flink on YARN、Kafka、HBase、Redis等组件的操作,我们将简要说明操作步骤,并提醒用户如何查看和截图。 注意:由于代码较长,我们将分块编写,并给出关键部分的代码。 步骤1:数据清洗和分发(备份到HBase) - 消费Kafka的topic1和topic2 - 根据数据内容(如表名)将数据分发到不同的DWD Topic - 同时将原始数据写入HBase 步骤2:实时指标计算 - 消费DWD层的Topic(例如fact_order_master等) - 计算商品UV(需要根据用户ID去重)和PV(访问量),写入HBase - 计算每分钟GMV(可以根据订单表的订单金额,按每分钟窗口汇总),写入Redis 由于涉及多个组件,我们需要确保: - 添加相关依赖(在pom.xml中) - 配置文件(如kafka、hbase、redis的连接配置) 由于代码量较大,我们只给出关键代码片段,并说明思路。 首先,我们实现第一个作业:数据清洗和分发。 假设topic1(ods_mall_log)和topic2(ods_mall_data)的数据都是JSON格式,其中topic2的数据包含表名(table)和具体数据(data)。我们只处理topic2中表名为fact_order_master和fact_order_detail的数据,将其分别发送到对应的DWD Topic,其他表忽略。同时,将两个topic的原始数据都备份到HBase。 备份到HBase:我们可以设计一张HBase表,例如命名空间为backup,表名为ods_mall,列族为info。rowkey设计为topic+分区+偏移量(或者时间戳+随机数确保唯一),列存储原始数据。 然后,第二个作业:实时指标计算。 - PV:每来一条记录(表示一次访问)就计数一次,按商品ID和每分钟分组。 - UV:需要按用户ID去重,按商品ID和每分钟分组。 - GMV:从订单主表(fact_order_master)中读取订单金额(假设字段为order_amount),按每分钟窗口求和。 由于用户要求使用Java,下面我们用Java代码实现。 注意:在实际编写时,需要根据实际数据格式解析。 我们先写第一个作业(DataCleanAndBackupJob)的代码框架: </think>以下是为您编写的Java+Flink实时数据处理解决方案,包含代码实现和操作指导: ### 一、数据清洗与分发作业(Flink on Yarn Per-job) ```java // DataCleanJob.java public class DataCleanJob { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setRuntimeMode(RuntimeExecutionMode.STREAMING); // 消费Kafka原始数据 Properties kafkaProps = new Properties(); kafkaProps.setProperty("bootstrap.servers", "kafka-broker:9092"); DataStream<String> sourceStream = env .addSource(new FlinkKafkaConsumer<>( Arrays.asList("topic1", "topic2"), new SimpleStringSchema(), kafkaProps )).name("kafka-source"); // 数据清洗分流 sourceStream.process(new ProcessFunction<String, Tuple2<String, String>>() { @Override public void processElement(String value, Context ctx, Collector<Tuple2<String, String>> out) { try { JsonObject json = JsonParser.parseString(value).getAsJsonObject(); String table = json.get("table").getAsString(); // 备份所有数据到HBase backupToHBase(json.toString()); // 订单主表/明细表分发 if ("fact_order_master".equals(table) || "fact_order_detail".equals(table)) { out.collect(Tuple2.of("dwd_" + table, json.get("data").toString())); } } catch (Exception e) { // 异常数据处理 } } }).name("data-processor") .addSink(getKafkaSink()).name("dwd-sink"); env.execute("Data-Clean-Job"); } private static void backupToHBase(String data) { // HBase连接配置 Configuration config = HBaseConfiguration.create(); config.set("hbase.zookeeper.quorum", "zk-node1,zk-node2"); try (Connection conn = ConnectionFactory.createConnection(config); Table table = conn.getTable(TableName.valueOf("backup:raw_data"))) { Put put = new Put(Bytes.toBytes(UUID.randomUUID().toString())); put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("raw"), Bytes.toBytes(data)); table.put(put); } catch (IOException e) { // 异常处理 } } private static KafkaSink<Tuple2<String, String>> getKafkaSink() { return KafkaSink.<Tuple2<String, String>>builder() .setBootstrapServers("kafka-broker:9092") .setRecordSerializer(new KafkaRecordSerializer()) .build(); } static class KafkaRecordSerializer implements SerializationSchema<Tuple2<String, String>> { @Override public ProducerRecord<byte[], byte[]> serialize(Tuple2<String, String> element, KafkaSinkContext context, Long timestamp) { return new ProducerRecord<>( element.f0, // topic name null, System.currentTimeMillis(), null, element.f1.getBytes(StandardCharsets.UTF_8) ); } } } ``` ### 二、实时指标计算作业(GMV/UV/PV) ```java // MetricComputeJob.java public class MetricComputeJob { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.enableCheckpointing(60000); // 消费DWD层订单数据 DataStream<OrderEvent> orderStream = env .addSource(new FlinkKafkaConsumer<>( "dwd_fact_order_master", new OrderDeserializer(), getKafkaProps() )).name("order-source"); // 每分钟GMV计算 orderStream .keyBy(e -> 1) // 全局统计 .window(TumblingProcessingTimeWindows.of(Time.minutes(1))) .aggregate(new GMVAggregator()) .addSink(new RedisSink<>()).name("gmv-sink"); // 商品UV/PV计算 DataStream<ProductView> viewStream = ... // 从dwd_fact_log获取 viewStream .keyBy(ProductView::getProductId) .window(TumblingProcessingTimeWindows.of(Time.minutes(1))) .aggregate(new ProductStatsAggregator()) .addSink(new HBaseSink()).name("product-sink"); } static class GMVAggregator implements AggregateFunction<OrderEvent, Double, Double> { @Override public Double createAccumulator() { return 0.0; } @Override public Double add(OrderEvent event, Double acc) { return acc + event.getOrderAmount(); } @Override public Double getResult(Double acc) { return acc; } @Override public Double merge(Double a, Double b) { return a + b; } } static class RedisSink<T> extends RichSinkFunction<T> { private transient Jedis jedis; @Override public void open(Configuration config) { jedis = new Jedis("redis-server", 6379); } @Override public void invoke(T value, Context context) { String key = "gmv:" + System.currentTimeMillis()/60000; jedis.set(key, value.toString()); } } } ``` ### 三、操作指导与数据查看 #### 1. 作业提交(Yarn Per-job模式) ```bash # 打包作业 mvn clean package -DskipTests # 提交清洗作业 flink run -m yarn-cluster -yn 2 \ -c com.DataCleanJob \ target/flink-job.jar # 提交指标作业 flink run -m yarn-cluster -yn 4 \ -c com.MetricComputeJob \ target/flink-job.jar ``` #### 2. 数据验证方法 | **组件** | **查看命令** | **截图要点** | |----------|--------------|--------------| | **Kafka DWD层** | `kafka-console-consumer.sh --topic dwd_fact_order_master --bootstrap-server kafka:9092` | 展示分流后的JSON数据结构 | | **HBase备份** | `scan 'backup:raw_data'` | 显示原始数据备份条目 | | **Redis GMV** | `redis-cli -h redis-server KEYS gmv:*` | 展示每分钟GMV键值对 | | **HBase商品统计** | `get 'product_stats', 'product_id_123'` | 显示UV/PV时间序列数据 | #### 3. 截图保存技巧 1. **Kafka数据**:使用`kafka-console-consumer`输出重定向到文件 2. **HBase数据**:使用`hbase shell`配合`export`命令导出表数据 3. **Flink UI**:访问`http://yarn-resource-manager:8088`截图作业运行状态 4. **数据验证**:使用Jupyter Notebook可视化Redis/HBase数据生成趋势图 > **注**:完整实现需补充的部分: > 1. HBase表预分区设计(按时间范围) > 2. Redis连接池优化(使用JedisPool) > 3. Flink状态后端配置(建议RocksDB) > 4. 异常处理与重试机制(Kafka提交偏移量) ### 关键配置优化建议 ```yaml # flink-conf.yaml execution.checkpointing.interval: 60s state.backend: rocksdb state.checkpoints.dir: hdfs:///flink/checkpoints restart-strategy: fixed-delay restart-strategy.fixed-delay.attempts: 3 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值