doc: fix broken links in markdown (#4880)

* docs: fix broken links in markdown * Update docs/consistent-hash.md Co-authored-by: August <[email protected]> Co-authored-by: TennyZhuang <[email protected]> Co-authored-by: August <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
risingwavelabs · Aug 29, 2022 · b60803f · b60803f
1 parent bc3933d
commit b60803f
Show file tree

Hide file tree

Showing 6 changed files with 7 additions and 8 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -11,7 +11,7 @@ To report bugs, create a [GitHub issue](https://github.com/singularity-data/risi
 
 ## Table of contents
 
-  - [Tests and miscellaneous checks](#misc-check)
+  - [Tests and miscellaneous checks](#tests-and-miscellaneous-checks)
   - [Submit a PR](#submit-a-pr)
     - [Pull Request title](#pull-request-title)
     - [Pull Request description](#pull-request-description)

diff --git a/docs/architecture-design.md b/docs/architecture-design.md
@@ -16,7 +16,7 @@ There are currently 3 types of nodes in the cluster:
 
 The topmost component is the Postgres client. It issues queries through [TCP-based Postgres wire protocol](https://www.postgresql.org/docs/current/protocol.html).
 
-The leftmost component is the streaming data source. [Kafka](https://kafka.apache.org) is the most representative system for streaming sources. Alternatively, [Redpanda](https://redpanda.com/), [Apache Pulsar](https://pulsar.apache.org/), [AWS Kinesis](aws.amazon.com/kinesis), [Google Pub/Sub](https://cloud.google.com/pubsub/docs/overview) are also widely-used. Streams from Kafka will be consumed and processed through the pipeline in the database. 
+The leftmost component is the streaming data source. [Kafka](https://kafka.apache.org) is the most representative system for streaming sources. Alternatively, [Redpanda](https://redpanda.com/), [Apache Pulsar](https://pulsar.apache.org/), [AWS Kinesis](https://aws.amazon.com/kinesis), [Google Pub/Sub](https://cloud.google.com/pubsub/docs/overview) are also widely-used. Streams from Kafka will be consumed and processed through the pipeline in the database. 
 
 The bottom-most component is AWS S3, or MinIO (an open-sourced s3-compatible system). We employed disaggregated architecture in order to elastically scale the compute-nodes without migrating the storage.
 

diff --git a/docs/consistent-hash.md b/docs/consistent-hash.md
@@ -24,7 +24,7 @@ For all data $k \in U_k$, where $U_k$ is an unbounded set, we apply a hash funct
 
 ![initial data distribution](./images/consistent-hash/data-distribution.svg)
 
-Then we have vnode mapping, which ensures that vnodes are mapped evenly to parallel units in the cluster. In other words, the number of vnodes that are mapped to each parallel unit should be as close as possible. This is denoted by different colors in the figure above. As is depicted, we have 3 parallel units (shown as circles), each taking $\frac{1}{3}$ of total vnodes. Vnode mapping is [constructed and maintained by meta](https://github.com/singularity-data/risingwave/blob/main/src/meta/src/manager/hash_mapping.rs).
+Then we have vnode mapping, which ensures that vnodes are mapped evenly to parallel units in the cluster. In other words, the number of vnodes that are mapped to each parallel unit should be as close as possible. This is denoted by different colors in the figure above. As is depicted, we have 3 parallel units (shown as circles), each taking $\frac{1}{3}$ of total vnodes. Vnode mapping is [constructed and maintained by meta](https://github.com/singularity-data/risingwave/blob/main/src/meta/src/stream/scheduler.rs).
 
 As long as the hash function $H$ could ensure uniformity, the data distribution determined by this strategy would be even across physical resources. The evenness will be retained even if data in $U_k$ are skewed to a certain range, say, most students scoring over 60 in a hundred-mark system.
 

diff --git a/docs/relational_table/storing-state-using-relational-table.md b/docs/relational_table/storing-state-using-relational-table.md
@@ -1,7 +1,7 @@
 # Storing State Using Relational Table
 
 - [Storing State Using Relational Table](#storing-state-using-relational-table)
-  - [Cell-Based Encoding](#cell-based-encoding)
+  - [Cell-based Encoding](#cell-based-encoding)
   - [Relational Table Layer](#relational-table-layer)
     - [Write Path](#write-path)
     - [Read Path](#read-path)
@@ -38,7 +38,7 @@ For the detailed schema, please check [doc](relational-table-schema.md)
 
 <!-- Todo: link cconsistence hash doc and state table agg doc -->
 ## Relational Table Layer
-[source code](https://github.com/singularity-data/risingwave/blob/main/src/storage/src/table/state_table.rs)
+[source code](https://github.com/singularity-data/risingwave/blob/4e66ca3d41435c64af26b5e0003258c4f7116822/src/storage/src/table/state_table.rs)
 
 In this part, we will introduce how stateful executors interact with KV state store through the relational table layer.
 

diff --git a/docs/streaming-overview.md b/docs/streaming-overview.md
@@ -9,7 +9,6 @@
   - [Checkpoint, Consistency, and Fault tolerance](#checkpoint-consistency-and-fault-tolerance)
     - [Barrier based checkpoint](#barrier-based-checkpoint)
     - [Fault tolerance](#fault-tolerance)
-  - [Advanced features](#advanced-features)
 
 <!-- Created by https://github.com/ekalinin/github-markdown-toc -->
 
@@ -61,7 +60,7 @@ The underlying algorithmic framework of RisingWave streaming system is the tradi
 
 ## Checkpoint, Consistency, and Fault tolerance
 
-We use the term consistency to denote the model of the *completeness and correctness* of querying materialized view. We follow the consistency model introduced in [Materialize](https://materialize.com/blog-consistency/). More specifically, the system assures that the query result is always a consistent snapshot of a certain timestamp t before the query issue timestamp, and later queries always get consistent snapshots from later timestamp. A consistent snapshot at t requires that all messages no later than t are reflected in the snapshot exactly once while all messages after t are not reflected. 
+We use the term consistency to denote the model of the *completeness and correctness* of querying materialized view. We follow the consistency model introduced in [Materialize](https://materialize.com/blog/consistency/). More specifically, the system assures that the query result is always a consistent snapshot of a certain timestamp t before the query issue timestamp, and later queries always get consistent snapshots from later timestamp. A consistent snapshot at t requires that all messages no later than t are reflected in the snapshot exactly once while all messages after t are not reflected. 
 
 ### Barrier based checkpoint
 

diff --git a/src/README.md b/src/README.md
@@ -9,7 +9,7 @@ Almost all components of RisingWave are developed in rust, and they are split to
 5. `frontend` contains our SQL query planner and scheduler.
 6. `storage` contains our cloud native storage engine, read [State Store Overview][state-store] for more details.
 7. `meta` contains our meta engine, read [Meta Service][meta-service] for more details.
-8. `util` contains several independent util crates which helps to simplify development. We plan to publish them to [crates.io](crates.io) in future when they are more mature.
+8. `util` contains several independent util crates which helps to simplify development. We plan to publish them to [crates.io](https://crates.io/) in future when they are more mature.
 9. `cmd` contains all binaries, and `cmd_all` contains the all-in-one binary `risingwave`.
 10. `risedevtool` is an awesome developer tool for RisingWave, read [RiseDev Guide][risedev] for more details.